Um, so with that, uh… people, fingers on the button for record, if you could push the record buttons.
Well…
Hey, Stan.
Dan, you… you go too, Stan?
It's… go ahead.
Oop, lost the connection. That froze. Stan killed it.
I mean, maybe killed the video to… provide more bandwidth for audio.
Oh, there he is, he's back. He's back, alright. Okay, this is the bookend for tonight's meeting. This is the St. Louis Linux Users Group.
St. Louis Lug. Uh, today's date is Thursday, the 19th of June.
2025. Our speakers tonight will be, uh, uh. Legal Amirage and, uh, Grant Taylor.
And they're going to be talking to us about the evolution of SSL, socket security layer to TC… T… Pardon me? Tls, thank you. Uh, transport layer security.
Uh, so that's why we need to talk, is to get Gary to get the initials right.
Okay, with that, um… For those of you who aren't… who may be, uh, unfamiliar with our group, or this may be one of the the view of the first times you've come.
Uh, this group has been around for over 3 decades, I think?
And, uh, um… We, uh, try and… even though the name of this meeting is the Linux User Group.
Uh, we're part of a slightly larger organization, St. Louis Unix Users Group.
Linux is, of course, a type of Unix. Uh, and uh… Um, we really kind of take care of anything that's in an open standards or open source, open systems.
Anything non-proprietary interest, uh. We like to get our nose into.
Um, there's, uh… Stan, do we have a slide deck to go with the… Intro here?
Now that I… Zoom is doing another nasty thing to me again. I can't… All the buttons went away on the machine.
Okay. Well, Stan looks into that. I'm gonna wing it a little bit, then.
Stupidity.
We generally have four meetings, as most of our users may be interested in a month.
Two of them, uh, have presentations, like tonight, so it's the St. Louis Lug Meeting on the Usually, it's on the third Thursday, but it's always 8 days after The St. Louis Unix user group general meeting, and that is always on the second Wednesday of the month.
And, uh, both of those have a presentation, uh. With a fixed title, an abstract, a speaker.
And, uh, so you kind of know what you're coming for.
There's two other meetings that we do every month. One is called the St. Louis Area Computer Club.
And the other one is called the New Users Linux Meeting.
And, uh, those two do not have a presentation. There's no fixed subject.
Uh, the difference between them is the, uh, St. Louis Area Computer Club almost empty.
You don't know the group, do you, Gary? You have no idea!
Yeah, no idea. That group is, uh, starts out being more hardware-oriented, so it's just kind of, you know, the basics of computers.
Of, you know, how you can put a box together, what operating system works.
They'll even talk about, you know, Microsoft things in that group.
Uh, so, uh, and it's all just free farm. It's whatever people ask and want to talk about.
And, uh, the other group, the new users, uh, meeting. Whoever considers themselves the newest person to Linux gets to ask the first question.
And that starts the conversation, and uh… Um, don't be afraid of the title, New User of Linux, uh, because getting the old hands, the more familiar people in on that meeting, of course, are the ones who are coming up with the answers.
And it's really amazing. You may think that you know Yeah. Well, I know all kinds of things, right?
But when you go to these meetings and somebody asks a question, and all of a sudden, somebody else who's considered an old gray hair.
Gives a completely different answer than you would have given, and it's like a whole different approach, so it's kind of interesting going through that, so… Um, and then there are other things, like our steering committee, uh, meetings, things like that, that you're welcome to come to.
But there's two mailing lists you might be interested in. One is the Discuss mailing list. It's kind of a… a free form, uh… post your comment, your question, and… Other people were signed up to that mailing list.
Respond to it. The other one is the announce mailing list.
That's basically an edited thing that… one of our editors, volunteer editors.
I'll do, like, send out a notice, like, this meeting tonight. We'll send out the abstract and when it is.
Um, so it's a much less, or much more limited, uh, quantity of information than that.
So, a limited number of mailings, I think I should say.
Um… let's see… the, uh, the opposite.
We do at this point in the meeting. Grant, you want to say something?
I was gonna say sysadmin mailing list for… talking about supporting the SLUG infrastructure.
Groups being made technical sausage being made.
Yeah, yeah. Uh… Exactly. And, uh… I guess I usually don't mention that one right away, because it… We've questioned the security of it, you know, of publicly telling people they can subscribe to the mailing list.
Uh, but you can, and uh… but it's mostly for the guys who are We, the user group, maintains a couple of servers.
And, uh, so, yeah, that's where… the people who want to… want to help maintain these machines do the upgrade to the next version of Linux, uh.
Check and make sure network security is working. See if the TLS is the most current version.
Uh, that's… that's where these kind of discussions would take place, but… Not so much as a just general… whole-home discussion as much as, uh, here's the problem we've got to solve by next week. Um, so… gets a little work done, though.
Um. At this point in the meeting, um… Uh, we basically do announcements.
And then a short, um… general Q&A.
Uh, just if anybody has something that went wrong this week, and they want to ask that up front.
We'll do it now. Uh, kind of limited the thing on the front of the meeting.
And we'll also do a much longer, uh, general Q&A at the end of the meeting, but if you've got to leave early.
Um, you can… you can put your question here in the front.
So, with that, uh, any other announcements I'm missing? I don't think so, although the last weekend of the month, you might want to think about, uh.
Gone, uh, pizza session. Okay? Uh, I think what Lee is referring to is kind of the same thing that Sam was referring to a minute ago.
This is a weird month, in that the entire last week of the month, uh… is off our schedule. There is no scheduled meeting that we have.
Um, and so, yeah, it's a week when maybe we could schedule something.
Um, so one suggestion has been just have a physical face-to-face meeting, don't… don't worry about putting it on the network. And I believe we're talking about July now, right?
July. Last week of July. Yep. And, uh, so that's one option. Another option would be if somebody's got a particular topic that we could do a a Zoom-type meeting.
We consider doing that, too, so… Anybody who has an idea, either speak up now, or… But it's not meant in the, uh… online chat, or you can send us an email later.
Lee, can… Lee, can you make me Lord, uh… co-host, lowercase.
Closer to… yeah.
Got you covered. That having been said, anybody have any questions they want to ask up here on the front?
Um… Gary, can you hear me?
Yes, sir.
Thank you. I just had a question for Stan. I'd like to talk to you for a few minutes right after the meeting.
Okay.
I'll call you on… well, we could do it here on a Zoom, or we can… I can call you on the phone, whichever you prefer.
We'll stay on the Zoom. Stay on the Zoom.
Okay. That works just fine.
And, uh, I'll make the comment, uh… Those of you who… who… either your first time to one of our meetings, or haven't been to one of our meetings in a long time.
We're always curious as to what brought you here tonight. Uh, so… Uh, you can either just make a comment in chat, or, uh.
Um, you can just let everybody see it, or if you want to make it more personal, you can send the trap to me personally.
Our stand, and just say, yeah, so-and-so invited me, or, oh, I saw this topic advertised on Meetup and thought, oh, I want to go to that topic, so… Yeah, we're just curious what… what got you to come here tonight.
Any other general questions?
Okay, hearing none… I think… We should turn it over to our speakers this evening.
So, as I said, our speakers this evening… are Lee Lambert and Grant Taylor.
And uh… I'll turn it over to these guys, and we'll see what we can find out about TLS security.
Uh, before we do, is Stan trying to show something there?
Well, I've just shown the website, and… on the website that… That slideshow for… is right here.
It's below the link here. It says St. Louis links meaning. That's… that's the whole thing right there. That's just… The thing that was… Normally, we bring up, and… rattle through, and… Because Gary can't remember all these 12 slides, so…
Whatever. But everybody can go to the website, and… Ta-da, that's it. And I can stop my sharing.
Okay. Well, I shall pick it up, then.
The topic was raised, so… earlier, a while back, and… you know, the question was, what would people like to hear about?
And the topic was thrown out about security.
So that kind of evolved into discussion. Grant and I started talking about it.
And we put together a slide deck. Because there have been some changes in the last… what, 12, 13 years?
And sometimes it gets kind of confusing. For years a while back, I couldn't figure out what there is between SSL and TLS was.
Except you had TLS most of the time, and SSL some of the time.
So, we decided to talk about it. And Grant will chime in on… at any point, because he's our subject matter expert.
Oh, God.
And I've been playing with a slide deck for the last 2 days, trying to get it working better than it was last time, but… I'm not making too much progress on it.
If anybody has played with Reveal.js, which seems to be one of the most usable ones, and has been able to keep the presentation in a separate Markdown file.
And yet, still include formatting in the Markdown file. Please let me know, because ChatGPT has been unable to solve the problem for me.
Whoa. Ai couldn't do it? Wow.
Nope. In fact, I had to tell it to go kiss off, because it kept repeating suggestions.
Got stuck on not a loop, but… Anyway, back to the topic tonight.
I'm sure everybody's heard of SSL, because it's been used in websites for… close to 30 years.
There have been a number of implementations, a number of projects involved, which we'll talk about here in a few minutes.
But about 15 years ago, it started showing its age.
And there were security issues. That cropped up, and there are also some political issues involved. Again, we'll… we'll talk about them in detail.
So it was pretty much replaced with TLS. Tls is the modern, the current version is 1.3.
It is used to secure communications between pretty much everything on the internet. In other words.
Client-to-server communications with a website. With email.
And a whole bunch of others. And it's a fundamental mechanism people use today to stay secure.
Ssl started out a long time ago. It was the first tool used to secure websites.
Created in the 90s. Again, basically for website use.
It was the originator of the padlock in your browser that indicated HTTPS was valid.
So what means HTTPS is valid? Grant, you want to give us a few details here?
Um. I'm trying to think about how to say it. Basically, it means that… your client… nose… thinks the certificate, the math behind it is correct.
It's between the… use not before and not after, so it's in the valid date range.
And newer checks check to make sure the host name you're connecting to is part of the certificate you're going to.
That wasn't always the case, but it's just some basic sanity checks.
Does the encryption between the client and the server pass the sniff check? Or has the milk gone bad and it's time to pour it out, type thing.
Note, none of that speaks at all to… is this stuff the going from that website safe to see or not?
It is purely the communications between your web browser client and the web SERP.
Can you go back to that last point you made? The… the… I don't know if I understood that.
Um, HTTPS, or TLS, or SSL is purely about the communications path.
It says nothing about what is communicated through the path.
In other words, it can't say anything about the data, just that It was indeed the data transmitted from that server intact. Yeah, okay.
Correct.
And along the way, we've developed various mechanisms and implementations which can get pretty complicated.
Of some validation that the server you're talking to certificate does belong to that server, and you can trace that back to the issuer through their certificate chain.
It says, yes, yay, VRLE, that should be the machine that this server was issued to. Again, there's a lot of caveats along the way, but that's part of the handshake process.
Yeah, uh, another… common example of the failure scenario.
Was during the early 2000s. People would often think Well, the website I'm going to has a padlock.
Up in the address bar, so it means it's safe. To put my credit card information in it, right?
But that has nothing to do with if it's a hacker's bogus website.
With a valid TSL certificate. Tls certificate.
To, um… take your credit card information and go have a holiday at your expense.
Yep, yep. Perfect.
Does that make sense, Gary? Okay, um, I'm seeing chat pop up a few times. Do we have some questions in there?
Stan is having internet woes. Alright, go ahead, Lee.
Okay. Originally, SSL used RSA key exchange, which was fairly productive. It was about Originally, it was about the only way to do it.
But over the years. So, various hacks, which we'll talk about here in a little bit.
Meant that RSA wasn't necessarily something that you could really trust.
And so other ways of passing the keys and validating were developed, and again, which we'll introduce here in a few minutes.
If there's anything you want to add, Brian, just feel free to chime in. Mr. Subject Matter.
Uh, the protocol structure included a record layer. In other words, once the key exchange was passed.
Than the actual data was encrypted in a symmetric encryption after the handshake.
Ssl 2.0 was originally released in 95, SSL 3.0 in 96.
Which is a little bit less than 30 years ago. So, there's a lot of time in between there where technology improves, systems improve, networks got faster, which made hacking simpler and quicker.
So those problems tended to elevate in importance. In the, you know, mid-2000s.
There is a very good chance the phone that's probably in your pocket now has more processing power than governmental agencies had 30 years ago to brute force the math.
On certificates.
Yeah. Yeah, I did just one aside, I will blow you away.
35 years ago, by hook or crook, I actually got to spend the day on the Alabama.
The boomer saw about in… out in, uh, Washington State. The biggest computer most powerful computer on the sub.
Was a compact 286. And that just blew me away.
So things have changed a lot since then. Could you jump back? Oh, sure.
Okay, the, uh, the fourth bullet. Living RSA key exchange.
So, is that then saying that, uh. Fine. I've been… exchanging information with a particular website for a month now, and as of today.
Someone has cracked my key. Well, you're not gonna crack the key, somebody has stolen your key. Somebody has stolen the key.
Well, mathematically, keys from then could be brute-forced now.
Yes.
Yeah, with today's hardware. So, so… but… but that… that point, point number four there is basically saying that If someone has saved.
All of the back-and-forth communication for that month. Once you cracked the key.
You've got the whole month's worth of communication available to you.
Yes. And that is one of the weaknesses that was discovered.
And is addressed in later versions. The initials are PFS, And I believe it is… we're going to talk about it in the slide.
All right, anybody else?
Is that why the NSA records absolutely everything?
That is one of the ideas that is speculated. Um, there is a very real if we save the encrypted data.
We may get the keys and be able to decrypt it at some unknown point in the future.
Okay. Some side notes here.
House of Representatives disability.
Ssl originated who were originally created by Netscape.
This was back in the 90s. Ssl 1.0 was never released.
Due to serious flaws. And we mentioned a minute ago about 2.0 and 3.0.
Another sidebar. Openssl. We started as a fork of SSLea.
Which was Eric Young and Tim Hudson. I remember SSLA… SSLEA floating around back then when we had to build it with floppies on a… computer where we had to install the TCP IP stack on the computer.
It was widely adopted, but half a million lines of C.
It was very fragile. And Heart Bleed from 2014.
Was a major breach. I always call it a breach or not, but a major flaw in the protocol.
That was exploited, and it was a major dust-up.
After that, LibreSSL was… was, uh, created by OpenBSD and Boring SSL by Google.
They were both forks to improve reliability and security.
Um, one of the reasons that LibreSSL and Boring SSL came about.
Is many consider OpenSSL to be a reference implementation.
And your reference tends to have almost all of the capabilities, not necessarily all of which are needed.
But that complexity brings some exposure to it. So, one of the things Libre, SSL and Boring SSL did is they've reduced… were omitted features that were not needed, particularly for their use case.
Thus reducing the size of the code base, and thus enhancing.
The security of the code base.
Okay. Yeah. Okay.
Part of this pic… go ahead. So jump back to that thought, Grant or Lee So, what would be some examples of Something that would be considered, uh… to, uh… too esoteric, and… There will pop out of LibreSSL.
Um. It's not necessarily too esoteric, but… OpenSSL includes support for SMIME encrypted email and multiple other things.
That… that section of code is never used between a web browser client and a web server. So that is an entire chunk of code that Google was able to not include in their SSL implementation.
It's kind of like, um… If you think about… early, over-the-road trucks.
They did not include many features, or if you look at NASCAR cars today.
They tend to not include headlights, because they're on a lighted track.
It's just different optimizations that Well, we never do that in this use case, so don't include that code.
Does that make sense?
Yeah. Okay.
All right, another part of the picture was the browser wars.
Microsoft developed their PCT, Which was based on SSL 2.0.
Pretty primitive by today's standards. Netscape Respo responded with SSL 3.0.
And at that point, again, this was in the 90s, the competition was really hot.
To define an internet encryption standard. And there's a whole lot of subplots going on back then, because There was no clear winner.
You know, everybody had an advantage in their… playing field. You know, Microsoft had an advantage, because they were… they were building Internet Explorer back then. They hadn't realized that that was a worthless project and give it up, like they did
When they came out with Edge about 12, 14 years ago.
And Netscape never could figure out how to make money at the process, so… They kind of dried up and blow… blew away.
Although, once… once that transition into Firefox and Thunderbird, then… they came up with a good community model.
To keep it going from an open source standpoint.
I'll also say, or add, that this time frame was very early in… well-known public computer cryptography, there were certainly government agencies.
But your general purpose computers It was nascent.
Cryptography. There were PGP, or was becoming a thing around the time, and… it had some major problems, and… the cryptography ecosystem hadn't really become what it is today, and there were still a lot of lessons to be learned.
Which… some of which are encompassed in the SSL TLS evolution.
Workday treating Cryptography, like munitions, also?
Yes, uh, in the 90s, um… I don't remember what the act was.
You could, in domestic, inside the U.S, and trusted allies. You could get 128-bit symmetric encryption.
I think it was symmetric. Um, but outside of those jurisdictions.
You could only export 56-bit encryption.
And that's why if you go looking at service packs and patches and things from old software from the 90s, if you're into retro computing.
You'll see reference to different service packs and cryptographic levels. Um, it was very much a thing, and the United States government had declared strong encryption, they treated it like munitions.
To ride the restrictions, export policies, and the likes.
The Internet Engineering Task Force. Wanted to formalize an open standard.
And Tim Dirks was helping. I forget who found… was that Stan? Was that Phil that came up with that article for her?
And basically, that process evolved SSL 3.1, into a new project, TLS 1.0.
Which was… politically set up to be neutral with no player in control, whether it be Microsoft, Netscape.
Google, whatever. Because it's a standard this… important to the network and security.
Does not or cannot have any single entity controlling it.
In fact, I wonder what Google's going to do once they're forced to split search from the rest of their, uh… I'll agree.
And I think that's actually a very fair comparison to the handoff of SSL from Netscape.
To the TLS over to IETF.
Um, it's… the same technological evolution just changing names and… changing administrative bodies. It's like you're, uh.
Restaurant down the block that has your favorite dish. Change names and has a sign under new management.
But they still have your favorite dish.
Hmm.
Here's an interesting timeline. 94, SSL 1.0, which was never released.
95. 2.0 was the first public release. 96 Netscape released 3.0.
As well as Microsoft. They created a PCT fork for their use.
In 99, SSL 3.1, was… I don't know if you… I don't know if you got… I don't know if you go forked or not.
Was turned into TLS 1.0. 1.1 and 06.
1.2 in 08. And notably, in 14, was the heart bleed… Heart Bleed.
Um, I don't know if you could technically call it a bug.
But it was a vulnerability. That was found in the OpenSSO libraries.
I do believe it would be classified as a bug, because it tended to be the implementation's did not sanity check some of the input from clients?
And would end up doing undesirable things.
Okay. And then 2018, 1.3, which was a major redesign.
And that is pretty much what we have today.
Okay, what… SSL was a great start, but did have some critical flaws.
We mentioned heart bleed here a little while ago. But some of the other notable ones were Poodle… Poodle, Beast, and Drown.
These were major flaws in the code. The algorithms were outdated.
The key length was not long enough for good security anymore, because the hardware standards to attempt, uh, to reverse engineer it were… outpacing the security inherent within the algorithm.
And I'm not sure what you mean by forward security. Grant, you want to comment on that?
Um, yeah, so the idea… you talked about on another slide is if some spy agency recorded encrypted communications, and then later got the key They could decrypt all of that.
Previously recorded information. Um, there… so, newer versions of TLS introduced what is called Perfect Forward Secrecy Um, or PFS.
Wherein you… a client and a server. Establish an encrypted channel And in doing so, they actually use the initial key set.
And then they use Diffie-Hellman Key Exchange to derive ephemeral keys that they use for that communications session.
They're… so it's… Each separate communication session uses separate keys.
So, if the NSA or pick your agency records information. Well, they'll get some handshake But they can't get the actual data, because the actual data was encrypted using ephemeral keys that only existed in memory of the client and server during that exchange.
And, uh, that's… that's a… major part of the handshake process The handshake with the publish key and private key on the server established the validity of that server to the client.
And then they both negotiate a separate key. For that conversation, and only that conversation.
That's used to encrypt the data.
So there's no way to recreate that key.
No, it's not. Um… brute force would be it.
Correct. Not… not once you terminate the session. Right.
So there's no way to recreate it However, the client and or server can save it.
Like, there's some environment variables you can set for Firefox or Thunderbird.
You activate during debugging. And it will actually record those ephemeral keys to a file.
But it's off by default, and you have to explicitly enable it, and you only do it under a certain situation.
So it's kind of like, Stan, you say. Um, talking about sensitive things on these presentations, anybody could record it!
Type thing, so the client or server can record those keys.
But without knowledge of those keys, you can't get to the data after the fact.
Okay. Anybody else?
So SSL today is… deprecated by all modern browsers.
And is officially retired and insecure. Although there are some issues where it can still raise its ugly head.
Because… you know, when we install a router.
It might be 15 years old. In fact, I had a problem last month.
Trying to get a browser to open the config page for the router was a major nightmare.
And, uh, I think Gary asked what would be an example of something that was removed from that may have existed in OpenSSL, but not in Libre or Boring.
Um, Libre and Boring SSL were some of the earlier ones to remove support for the older protocols.
Because they're not needed it's less code, but OpenSSL as the quote-unquote reference implementation.
Still had support for things.
Yeah, and I found out the hard way that the current version of Firefox, maybe one or two versions ago, actually removed TLS1 as an option.
Mm-hmm.
So I had to, uh, find a different browser. And it wasn't Chrome.
Okay, heart bleed. It was… Heart Bleed was a major… vulnerability slash bug that hit the press about a little over 10 years ago.
It was a bug in the heartbeat extension. To TLS, but it wasn't the protocol flaw.
It allowed memory. To be accessed during the process, passwords, keys, etc.
Affected millions of servers. And led to some… the publicity and remediation efforts.
That basically were worldwide at the time.
Yeah, um, if you were in the… computer business patching clients, or servers.
Uh, that was a rough month when that came out. Um, and I'm not into security like cyber professionals are.
But I think it's kind of interesting. I do not… I remember the… massive effort.
But I do not remember hearing about any breaches that utilized HeartBleak.
And it's probably very similar to Y2K of oh my gosh, there's a whole bunch of effort.
Put in place to remediate. Everything was taken care of.
And then it was smooth sailing.
All right, so 99 TLS. Try replacing SSL.
It's an open standard, actively maintained. It can be used in a number of applications.
Web traffic for HTTPS, Email is pretty much required nowadays for cheap… exchanging email between servers Because it provides a couple different functions.
To the email server, it gives you some assurance that the server you're sending to is verily that server the cert was issued to.
And also encrypts the traffic. You know, for the duration of that session.
Also used in VPNs and a heck of a lot of others.
Applications. We mentioned 1.1… 1.0 and 1.1 are deprecated. And again, I mentioned that the last couple versions of Firefox have physically removed the 1.0, So you no longer have an option of using that. If you need it.
To talk to a router. 1.2 is used in most applications today.
1.3 is in… becoming a standard.
But there are just so many machines out there that haven't Erka can't run 1.3.
You know, shoot, I've got 10 servers in the back room that can't even run 1.1.
You know, a lot of browsers can use 1.3, but a lot of times, other servers are have upgrade problems.
1.3. The one round-trip, uh.
What's the RTT stand for, sir? Say again?
Trip time. Round trip time.
On round-trip time, okay. Faster connections… why don't you take this one?
Um, so the key thing about what ground trip time is If you recall, a TLS connection has a 3-way handshake.
Um, so you had to establish the TCP connection with 3 back and forth, and then older versions of TLS and SSL had between, I want to say, 3 and 7 round trips to do… full negotiation of everything.
So, one round trip time. Significantly sped up the TLS piece.
On top of TCP. And it even took its further, and you can actually put some of that handshake traffic in the third part.
Of the TCP handshake. So it significantly shrinks the number of packets that go back and forth.
To establish an encrypted, secure channel between a client and server.
Um, we talked briefly about Perfect forward secrecy, uh, with, uh.
And that's elliptic curve, Diffie-Hillman Key Exchange. Elliptic curve is a newer thing that has become I don't remember what… when it came out, but it's based on geometric curves on a graph.
And figuring out number points. It… you get similar security with elliptic Curve, with fewer bits.
As you do with more traditional I don't think it's… RSA, but, um… the other algorithms that can be used.
It requires more bits to get a rough, comparable security.
So, fewer round trips. Better or shorter key links that provide comparable security makes that connection establishment much faster.
Um, and some of the push for that was web developers chasing absolute speed, talking about page load time.
If you look at some contemporary web pages. One webpage I'll pick on CNN may establish secure connections with 20 or 30 other servers.
So if you can establish those 20 or 30 connections. In one or two round trips instead of 4-7 round trips, you're making that whole process faster.
And that was a big thing a lot of people were chasing in the, uh.
Late 2000s and early teens. Um, encrypted SNI, before I talk about encrypted SNI, let me talk about SNI.
Or server name indication. That is a way for a TLS client, when it's establishing the TLS session with the server to say, hi, I'm trying to talk to TLS server example.com.
And that's important so the server can actually host example.com, example.net, whatever.example, on the same server.
And the server needs to know what you're trying to connect to so it can use the correct certificate to talk to the client.
The client gives that hint with server name indication. And that's all well and good, except we have some oppressive regimes around the world that like to watch and go, oh, you're trying to go to Google or Facebook or some other news outlet we do not approve of.
We're using deep packet inspection, we see your SNI to a banned name.
Kill that connection. So encrypted SNI was a variant where it actually… encrypts with a key from DNS, So that deep packet inspection couldn't determine, oh, you're trying to go to a banned site.
Kill it. Um… S&I has kind of fallen out of favor. It didn't work.
As well as had hoped, and there wasn't much adoption. There's still ongoing effort for that functionality.
There are a few different things in development. And that's still being shaken out to see what's going to become of that.
And as Lee mentioned to you before. Removed older key exchanges, ciphers.
Um, compression is a weird one. If you get into deep cryptographic theory.
If you can detect how compressible something is. That is actually… can be used as an information leak.
So, the pure cryptographic ecosystem trying to make things more secure says, no more compression, we're just cutting off that potential side channel leak.
Before we start. And the compression in older TLS and SSL versions harked from a time when a T1, or 1.54 megabit, was super fast.
Now, even the slowest cell phones are considerably faster than that.
Compression didn't really gain much. Who's an information leak, who's extra code.
It just got left on the cutting room floor for TLS 1.3.
There are three cipher Suites. And 1.3.
Aes-128, AES-256, And, uh… Cha-Cha20 Poly, 1305, SHA-256.
Anything, uh, interesting to say about these grants?
Um, you're getting into very deep things, and there's, um… I think you're actually… you could see the AES and SHA, they're… hashing algorithms, but they're used for different parts in there.
Is very, very deep. Very math-heavy.
Basically, for the pre… goal of the presentation tonight. Maybe recognize those. If you see them again.
It's… deep secret sauce, not so much secret, but it's… complex.
I guess the point is, we're talking about a minimum of 128-bit encryption.
And I'm not sure why AES-128 is in the same suite as SHA-256.
Is the 128 maybe the, uh… The comm encryption in 256, the key encryption?
Um, that… I would have to look things up. It's so deep, but yeah, it's probably a difference in the… asymmetric piece versus the symmetric piece.
So, a quick aside. As part of establishing a connection.
Asymmetric encryption, which is slow. Um, takes a lot of computing cycles, so that is used to establish an ephemeral symmetric key And then that symmetric key is used in another algorithm.
Um, so I believe that's where AES 128-bit will be used for one part, and SHA256 will be used.
For another part. I would have to go look up which is which.
Um, I've gotten very, very, very deep into TLS. And I have not needed to actually… get that deep. It's just… when I'm configuring things, I follow current best practices.
And I go, okay, TLS underscore AES underscore 128. That sequence of digits matches.
Tls 1.3.
See, client, hello, server, hello, finished, app. Data.
Yeah, um… So, the client hello is the client telling the server here's what I support.
Um, the ciphers and the key exchange methods. And there's the server name indicator, this is who I'm trying to connect to.
The server's response, um… picks the ciphers it supports and the keys out of the subset of what the client supports.
Sends its certificate, and that finishes… the, uh, handshake. That is the one round trip client-to-server and back.
And that's where number 3, the handshake is finished. And the secret… the key, secret keying material, or ephemeral secret key material.
Has been derived And both sides start using their ephemeral keys to exchange application layer data.
Any questions on that? I'm still percolating.
We're getting a deep stuff here. Good stuff. Cool.
Ssl versus 1.3. Key Exchange used to be static.
We're RSA. It's now elliptic Curve Diffie Hell Exchange. Which provides forward secrecy. Again, we talked about that already, because The key exchange process is asymmetric.
But the end… the result of that Kia change process is in effect… is a little bit shorter ephemeral key.
That is used to physically encrypt the data in both directions on that link from client to server.
And at the end of that conversation. That ephemeral key is thrown away.
So there is no way to take forward data.
With a key and decrypt it, you would have to, uh… physically, uh… develop the key yourself and hack the key.
With a random guess. That is possible. I'm sure NSA does it all the time. In fact.
I'm over virtually positive, they do. But they have the wallets to do it.
Very, very few commercial organizations would have that kind of resources or funding.
In the SSL world, many of the keys or the Cypher Suites were weak.
And 1.3… 256, and maybe 128-bit keys. What's AED grant again?
Um, I'd have to look it up for the exact algorithm.
But it's, um… authenticated… it's like the… message authentication code.
Is encrypted and signed. It's taking… super complex things, multiple of them.
To a higher order of magnitude. Um, things that just make my eyes spin.
All right, and we also mentioned round trips. On the handshake?
Ssl took 2. Tls can be done in one.
Which is a lot faster, especially if you have something slower than a gigabit connection.
The record layer… That's the data layer, right?
Payload layer.
Um, it's the… contents flowing through the encrypted channel.
Right, yeah, that's what I thought. In the SSL world, it's only partially encrypted. In the TLS world, it… everything is encrypted, including the handshake.
Shirt validation, the SSL world was… Where's, um… week, uh, it was easy to… avoid it, I believe.
In a TLS world, cert validation is now mandatory. In fact, there's been some discussions on, uh.
I think it was sysadmin, I don't… Recently, here.
That Google wants to use a change. So that, in simplified terms, a certificate cannot be used by a server to authenticate other communication streams not coming from that server. Is that the best way to say it, Grant?
Um… Yeah, I probably would describe it a little differently.
I'll, uh, throw this out there. So, my email server has its certificate from probably one of our favorite certificate authorities, let's encrypt.
And it can use that certificate to provide encrypted communications for people to hit my web server.
Or tip people to send my email server email over encrypted channels.
But my server can… primary server can authenticate itself using that certificate to a different server. Like, if it… once super enhanced.
Encryption to Gmail as our, actually, let's say I want to send an email to Lee at Omnitech my server can use its certificate while talking to Lee's server.
To authenticate cryptographically that it's my server.
That is a different use case. My server is the client.
Sending to Lee's server at that point. And there's… I think it's fair to call it some brouhaha.
Uh, going on in the… email community, the web browser community.
Uh, certificate authority browser forum. Um, with a decision that Google has made recently.
You'll see reference to server auth and client auth. And it's… there's… Google has thrown some weight around and said.
We're only going to do something, and other people have to toe the line, and… I think there's going to be some breakage, and there's already been some evidence of breakage from that decision.
Boy, okay, the last two lines here are just All kinds of good stuff in it.
Uh… Let me go back to where my question was here, standby.
Okay, for the record layer line. Partially encrypted versus fully encrypted.
Uh… Why? Why would they have had just partially encrypted earlier?
What, what, yeah.
Optimizations, and was encryption of everything necessary. And… I can't give an example, a concise example, inside of TLS, But, uh, PGP and SPIME encrypted email had a… flaw in some implementations, not necessarily the protocol.
We're in… part of the message is encrypted.
But bad actors… could prepend onto the front.
Or append onto the back. And then some buggy clients, when they went to display that email.
Would see the unencrypted. They would decrypt the part in the middle.
And then unencrypted at the bottom, and they would sandwich them together.
And display the whole thing. So, you can end up with… altering the content of the email… without being able to see the middle part.
Like, if you've done any, um… HTML coding.
Um, or really any language, I could put on the front.
Okay, I'm starting a multi-line comment. There's the encrypted data, which gets decrypted, and it appears as part of the multi-line comment.
And then at the end, I close the comment. And I put a forged body.
So, this… fake stack sandwich.
Your email client may think was an authenticated email. But it wasn't, because of the way it was manipulated.
Does that make sense?
Yeah.
Um, the idea with the TLS of partially encrypted, there were some very nasty ways that I believe similar could be done to TLS, where they could get some data in the packet before or after the encrypted portion.
And… alter the meaning of what was sent.
It's complex math. And it takes some… heavy lifting, but… older SSL, did not require everything to be encrypted.
Most well-behaved clients were assuming everything was But that assumption was an Achilles' heel.
Newer TLS, enforces that.
As a protection.
Is there another one, Gary? Oh yeah. Okay, yeah, let's go to the record later.
Okay. The next line, assert validation. May kind of get the same answer there, but… Why was it optional?
Okay.
Performance. Um… for web browsers, if you particularly remember back into the 90s.
A lot of people were on dial-up, and depending where you were, it might be slow dial-up, like 14.4 may be a good connection for you.
So, after you establish the TCP connection to the server, and it was multiple additional round trips.
To establish TLS, then your client would have to establish a additional TCP connection to the certificate authority's server.
And there were multiple exchanges in that. To be able to determine if the certificate that the server you're trying to get to.
Is valid. So, for performance reasons. A lot of clients, particularly mobile clients.
Elided that verification. And some that did… only did it partially.
Okay.
So, as the overall encrypted communications suite, SSL through TLS, evolved that validation is mandatory.
Okay, anybody else? I'm gonna… I… I wasn't paying close enough attention in chat, so… This goes back a half an hour ago. Uh, Chris.
Had posted, was the old hardware device managed by via web page, accessible via HTTP.
The context of that was when Lee was having problems getting a web browser to talk to a router.
A contemporary browser talking to an old router using old HTTPS protocols.
Chris, that, that, uh… I've seen enough of a fill-in on that?
Well, I… so that's when Chris asked it. I think that's more a question to Lee.
Could you have used HTTP Unencrypted to talk to the router.
I naively assume the router was following a newer standard, hey, you connect over unencrypted, let's redirect you to encrypted.
And you get into a cyclical loop.
Yeah, it was not possible to connect HTTP, because anytime you tried to connect, it would immediately switch over to HTTPS, in which case the cert was invalid.
So, Chris, uh, I hope we spoke to your question. And he says, thank you, you're welcome.
Fantastic. Excellent.
I… I do like interactive communications, even multimodal.
Alright, ML.
Okay. You know, we've all seen STLS replacing SSL, starting 12, 13 years ago.
It is extremely important for things like banking. Government operations.
Everybody knows HIPAA. Everything online you do now with medical.
Is secure, has to be secure, because that's what HIPAA says.
If you don't run a secure environment. You get big fines from the government, and people cast disparaging words your way.
So, online banking, email and chat. All kinds of web traffic a good… a TLS connection?
Pretty much prevents things like Each dropping, spoof sites.
Passive tracking. Although, the better the hacker and the more hardware resources they have, there are.
Probably some ways to get around it, but… with ubiquiti… with TLS pretty much being ubiquitous nowadays.
And especially… by removing the forward-level decryption, which we were talking about.
It's becoming a much more secure environment. In today's environment.
I don't have any statistics on it, but I suspect that people faking servers is a much bigger… way to make money in… illegally on the internet today.
Than it is trying to decode a… valid connection using TLS 1.3.
Absolutely. It has moved the attack method from simply… standing up a server with the same name.
Or even… now… to get a certificate you have to get… a different certificate authority to issue a cert with the same name.
And there are all sorts of things in place now to track that.
Uh, certificate transparency logging. And it is… becomes much, much, much harder to do.
And has moved the spoofing out of your high school student can intercept the teacher getting to Hotmail.
Realm to… big corporate… forcing some things for enterprise clients.
Or state-level actors, it… it has moved the problem domain to make it a much smaller problem.
So what we're seeing done now is homonym attacks where, uh, maybe I want to spoof PayPal.
I use, uh, some Unicode characters that look like PayPal, but… they're not the same characters And… it has moved the attacks to be much more complex.
Yeah, I see him every once in a while. Some… My mom used to… used to do it all the time. She'd see a link from PayPal.
And want to click on it, and then her screen goes wonky, and she calls me and says, Lee, what happened to PayPal?
And I'd have to say… tell her. Nothing, nothing. You're not talking to PayPal. Well, the link's in PayPal!
Well, it wasn't PayPal. Oh.
Um, so if you remember going way back here. Um, one of the problems computers had In the 60s and 70s.
Is people would just use a circle. For lowercase o, a capital O, or a zero.
And there were actual problems where people, like, well, what's your quantity? I've got 10 of these items, so, um, I put… I-0. It looks like a 1-0, or I, pardon me, put IO.
It looks like a 1 and a 0, but it's not… the number's 1-0.
And you kind of get into some homonym attacks like that. Now.
Well, I think even today. There are characters in the UTF-8 that look identical to your typical English, uh, letters alphabet.
Um, and so, to the human eye, you can't tell they look identical on the screen, but they're… the computer sees them as different.
Yep. Mm-hmm. So, we're seeing people, instead of Well, I just spoofed PayPal.
Without encryption, to now I have to do something much more complex.
Like that.
Yeah.
And this is where, uh, Password Vaults that are URL-sensitive It may have a perfect-looking PayPal landing page.
But your password vault goes, this isn't PayPal, I'm not putting your password in there.
Hickey, picky.
For a good reason.
Amen to that, you know, and just a side note, it amazes me. Everybody asks me, well, what's your password? I don't know.
How can you not have a password? I use a password vault. All my passwords are 50-character hashes.
Yeah. Which are unbreakable.
With today's technology, let's talk in 20 years.
Well, in 20 years, we can use 200 characters.
Yeah, and then there's also the XKCD. Lee has a 50-character password. Here's a $5, uh, wrench.
Go persuade him to give it to us.
I can't! I don't remember… I don't remember… I can't remember 50-character random hashes?
Sign into your password manager and give it to us. It's a perfect example.
I can! You stole my cell phone, it's got the authenticator on it.
And that's a perfect example of moving the attack from one problem domain to another one.
Yeah. If I log into my vault from a non… known system.
I have to have my cell phone with the authenticator so I can give it the six-digit character code that's valid for 30 seconds.
And I want to pause for a moment and say, Stan!
To validate the login.
Pay attention. Gary, pay attention! Repeat what you just said as for a future talk that we're gonna have on something.
Uh, speaking of which, uh…
Can you give me a title?
Well, it was what we talked about before the meeting of… what dealing with technology after people, um, pass on.
Oh, okay.
Yeah, I…
Because what Lee just described. Turns into a…
Oh, oh, oh, oh, I see the relation, yeah, okay. Thank you.
Yeah. I have a sealed note in my desk drawer here that has my vault key.
And all you need is the password to one of the computers.
Log into the vault with that ask key, and you've got access to… Every bank, every stock account.
Everything, you know. That it matters in my life, digitally.
All of which are using TLS…
Isn't that the equivalent of having a sticky note underneath your keyboard with your passwords?
You just… you just told everybody it's under… you just told everybody it's in your desk, right?
No, because there are no passwords.
Yeah?
The password to his password vault. When accessed from specific computers inside his house. Pardon me, inside his castle.
Which is not… directly breachable by somebody in, say, Mexico.
Oh.
Yeah, that's why it's a piece of paper, because it can't be hacked.
Right. People used to poo-poo the post-it notes for passwords.
And their attack domain is local. If you trust everybody in your local vicinity.
That post-it node. On the monitor is more secure than even some password vaults. Um, there has been some… news over the last 5 to 10 years, where well-known password vault.
Had some code leaked, and… keys were able to be brute-forced.
To get into the password vault. And if that happened, and the password was in the vault instead of on that post-it note.
An attacker in a foreign country could get to it. But they can't read what's on the post-it note stuck to the bottom of the monitor.
That's why they call and claim they're your tech support. And you have to change your password, so what's the old one?
And by the way, if that person can barely speak English.
Uh-huh.
It totally amazes me how many people would not question it.
Anyway…
It's bad… it's bad enough when I have to talk to AT&T for support for our dedicated fiber.
They're all Indian. Which is fine, because if you get about 4 levels up, you can actually talk to somebody that speaks good English and knows what the heck they're doing.
There's a very key difference you initiated that communication with numbers you identified to contact AT&T.
But if they call you. And say, hey, there's a problem.
There is that… who initiated, it makes a very big difference.
Yeah. But it's amazing how many people don't comprehend that.
Yep.
I'm going to point out that in the meeting chat. Uh, Doug R. Has posted a nice URL Uh, that, uh, gives a comparison of TLS implementations.
And before that, uh, Phil Bunch. And posted a URL for online certificate status protocol.
And another, uh… another URL for authenticated encryption.
Um, so, uh, so yeah, thank you, Phil. Thank you, Doug.
And I will say, Doug has raised his hand in the chat, or inside of Zoom.
Yep, hi guys, uh, Grant, this is for you. Thanks for bringing up the password vault one, by the way. That's been a big topic in my family recently.
And I have one question for you guys. Is the pass… because I think you made some excellent points there about the, you know, the post-it note and having it, if that's in your desk or it's hidden, that key.
That you use to encrypt the vault. Our discussion has been, you know, that password vault.
Or set of passwords is encrypted, and then it gets passed around to your cell phone and your other computer, and your laptop, and your… wherever you want to log in, but… It can only be decrypted by that that key that you've written down on the post-it note, right?
Um, it… you're asking a very, very, very good question.
And this is an evolving… field, much like TLS evolved from the 90s through the… Um, 20 teens.
Password Vault Access surviving their own owner.
And how to deal with it is… evolving. Um… Historically.
Prior to password vaults, the idea generally was have 3 people and give each of them like, half… of the password. And there was a certain way, an algorithm to do it, I don't know the details, I'd have to look it up.
So that any two of them could come together None had the entire password.
But any two could come together and derive the password.
Well, yeah. Yeah, I did read something on that recently. Yeah, that makes sense.
Um, and… So, we're starting to see password vaults incorporating some… features along these lines.
Um, and it kind of… Stan, all of this is very germane to the discussion that you said we wanted to have.
Um, if… The Password Vault Company.
Can produce the encrypted password under certain situations.
They can also do it under any situation, including sequestered court order with gag.
So, they can get to your passwords at any time. There are also some other ideas where you can give…
So, you're saying part of it should be kept offline? In that scenario.
Yeah.
Part of it, yes, and it's a very complex thing. And I actually come back with… The things I put in my password vault are there for my convenience.
There are offline processes if the password for my bank is lost, or the password for my utilities are lost.
I can go to the brick-and-mortar facility and show my government-issued ID, say, I lost my password, I need it to be reset.
And I think that is more the direction we need to see some online things go.
But that brings an end higher, different set of problems, and it's… not a game of cat and mouse, but it's kind of… We take two steps forward, take one step back.
Try to take two other steps forward, take one step back. We're inching forward.
But it's an evolving thing using a relatively new technology.
So you ask a wonderful question. There's not a great answer.
Um, one of the best things is… If your passwords last that long.
Put them in a spiral notebook. And put it in a safety deposit box.
If it is for things like… bank account, utilities, email.
Things that… people that can override established security, like I have a certificate of death for my grandfather, I was able to talk to AOL, I would like to take over ownership of his account.
They had a process, I had to fact… get something notarized.
Fax film something, and I was able to take over his account.
Through an established process.
It's new. And it's questions that… You're asking a great question. I don't have a good answer.
The split key, somebody, um… Shamir's secret, I think Phil said?
It's a current problem that's evolving.
The, uh, I think those are all great points, Grant. Thank you for bringing up the topic, and the main question I get asked all the time is people say, well.
Doug, my secret password file, I know it's encrypted, but obviously it's getting shipped through the internet when it goes to computer A, B, or C, which could be anywhere in the world.
Mm-hmm.
And my response to them as well. Yes, but you encrypted it on your device, so you're the only one that can decrypt it, because you're the only one with the password. No one out there in the cloud has your password.
And I just wanted to verify that I… I think that's what I read. Like, Firefox has a good description of how they do theirs, but… I think that's what it is?
And I will… I think… on the surface, and even a few layers below the surface.
I absolutely agree with what you have said. However, I bring to mind things like Microsoft Recall.
Where we're seeing unwelcome technology in client operating systems.
That are… we would have called this malicious activity 20 years ago.
That's marketing. It's not a good thing, it's marketing!
Yeah.
But now it's being billed as a good thing? So… Right. Um, in concept, yes. What you are telling people makes perfect sense, and I agree with Until you take into account, well, the computer is infected with a virus, or…
Right.
You lean passwords out of memory. You can only take reasonable steps you can't protect against everything. And you have to strike that balance.
And I think you were advocating a good balance.
Can I… can I ask you guys a second question?
Nope, not at all.
Um, I'm surprised that nobody's brought up, because all my friends and even my neighbors are bringing this up to me. They're like, Doug, quantum computing is coming, what about that? Isn't that gonna crack all the passwords? I get that.
Oh, there's… there… there's two things. Regarding that question.
Number one, who has access to it? You know, if your NSA and you've got $18 billion a year budget for computers.
Yeah, you might be able to. But are they going to waste… A lot of that $18 billion, Crack and Joe, you know, cracking your password?
Are you involved? What would their rationale be? And number two.
Even if it were… even when it is possible. What makes you a target?
Yeah, um… post-quantum cryptography.
Is an evolving field right now that I feel like is in its… somewhere between infancy and adolescence. Maybe I'm not correct.
Because I haven't been paying close attention to it. But I feel like we are still a long way away from quantum computers.
Being able to break established… encryption in a reasonable time for a reasonable cost.
So, what if you're willing to accept unreasonable time or unreasonable cost.
Like, if you're the government, and you have the ability to throw compute resources from across the country at it if you really want to.
Great. But if somebody has that type of resources. They can also black helicopter somebody and persuade them with a $5 wrench.
Yeah, I think those are both good points, too, and uh… it's… it's the younger kids that I know, people in their 30s and younger, that seem to believe that we're right on the edge in this quantum stuff is gonna… come, and we're gonna… all the banks are gonna not be able to keep their stuff encrypted anymore. And my response is usually, well.
Didn't we just a few years ago have a breach of one of the major, um.
Export bolts.
Right, just showing my, uh, memory. No, the, uh, uh, this… the people who maintain all your information about credit cards, the credit agencies.
Yeah, wasn't one of them hacked and they got everybody's info?
Well, credit bureaus.
So it's like…
Yeah, but that wasn't a hack, that was a phishing… fishing job.
Yes.
Uh, I think multiple have been compromised, and at least one of them it was done with more of what I would consider a hack, as in lack of security updates for 18 months.
On publicly accessible systems. Uh, but phishing is always a concern as well.
So I have a little bit of knowledge on the post-quantum cryptography stuff.
Um, so I have dealt with it. I've got some customers who are very interested in the financial sector.
Mm-hmm.
They're starting to develop standards, their security teams are starting to develop standards of what they're going to do.
Right?
Um, so NIST actually recently, I think, released their first set of standards last year, so there are several competing standards.
As there are when new things happen, uh, in the digital world. Uh, everyone wants to create their own standard.
Right.
Um, so we'll see what… what wins. But as of right now, there are… several ciphers that are quantum resistant, so they're mathematical equations are designed so that they are not easily cracked by what a quantum computer can do. Uh, that is beyond my knowledge. I can't get into the maths of it.
Um, but I can tell you that, um, so this talk is about, uh, TLS, for example. Um, they are starting to implement ciphers that are, um.
Quantum resistant, um… And so… so there are some ciphers that are… are being released for that. Um, so I… I work for Red Hat, uh, so, uh, REL10 just got released, um, here a few weeks ago, um, and one of the big
Features about that is, uh, there are several, uh, pieces in it that we've implemented, uh, for post-quantum cryptography.
Um, different ciphers and stuff to be able to start implementing those things. So while the standards are not solid, the technology is new and still being figured out, not 100%, um, there is work that is happening to day, because they see it on the horizon.
I think, as Grant was saying, no, most folks don't have access to a quantum computer that's cracking things. But, you know, eventually, just like today, our cell phones are super fast compared to the old computers. We probably will see that, and so work is being done Uh, to protect us in a post-quantum
Alright, very well said. Um, the… I think there's probably an analogy between what you have just said.
And if you look at it holistically, SSL and TLS 20 to 30 years ago.
I feel like quantum computing is going through that… Every vendor has their own thing, and they're developing standards and coming up with recommendations and learning and growing from each other.
How many people have access to a quantum computer?
You know, sure, but… you know.
Well, we… well, we don't know for sure. You know, they're…
I would… Pulling a number out of you-know-where, I'm gonna say 1,000 to 10,000 people in the world.
Really? That many, you think?
Yeah, what is access? Is it… scientists in labs.
Or is it people on the network that can access and do things?
And I feel… I would be shocked if less than a thousand people had access.
Now, it may be… you know, there's probably a hundred organizations creating quantum computers.
I mean, Google is working on quantum computers. How many people do you think are on the team working for Google that if they wanted to submit a test job to Factor 15, to the quantum computer.
I'd be willing to bet it's 10 to 100 people that could do that. And if you repeat that with organizations around the world.
Okay, a thousand.
Yeah, maybe so. I don't…
Ibm actually allows you free access to a cloud instance of a quantum computer. There's a limited amount of qubits that you get access to, but you can actually run quantum code for free, uh, within a certain restriction.
That blows by 10,000 number out of the water. Okay. That's very interesting to learn.
Yeah, I didn't know that.
That's IBM. I just put the link in the chat there.
Who did you say allows that, or offers that?
And yeah, it's not… I don't know if… much about quantum code.
So, but I believe you can't actually… they have some documentations on how to start writing quantum code, and you can run and compile it within I think I just read on there, I think, uh, you get 100 qubits, 10 free minutes of execution per month.
I'm sure you can pay for more if you really want to. I think the thing is.
Most folks outside of very sophisticated academics don't really know how to write code that does a lot with quantum computers, in the idea of what we think about in computers.
I think it'll be very interesting as things evolve. Much like different ciphers and hashes and various things about TLS.
Were attacked in the late 90s, early to mid-2000s. And onward. Um… as people start attacking post-quantum computing ciphers.
What happens if we start taking attacks for RSA, or ECDH, um… whatever that full acronym is.
And throw them at post-quantum cryptography. They should fail. But things like fuzzing find problems that nobody expected to see.
And it's a completely new world.
Whoever's talking, I don't know if you're close to your microphone.
We hear your voice, but I… we can't understand what you're saying.
That kind of sounded like a TV or something on in the background with an open microphone.
Thank you, Steve. Okay.
Matt, thank you for dropping that link in there. That really surprises me. I had no idea.
Leah, who we talk was successful, we can give a rat. We've enlightened people.
Grant, could I ask you one more question? Or for Lee or anybody?
No.
Uh, sure.
But yeah, so the basis of encryption… I think you guys are much further ahead than I am, but from what I learned many years ago.
I just want to check if this is still true. Isn't it based on factoring, like, prime fact… finding the prime factors of numbers, is that the basis of everything we're doing?
Um, that is the basis of… most… asymmetric encryption.
At least as I understand it, I am not a mathematician, I am not a cryptologists or cryptanalyst, I don't even pretend to be one.
But, yes, that is the idea. Of very large prime numbers that have…
For the product of two very large prime… are two very large primes.
The product of, which is nigh impossible. To factor to get those primes back out.
And that's public and private key. Or part of it. Um… Yes, and we're talking numbers… like, 1,024 bits in a number, all the way up to 40, 96, and I've even seen longer discussed elsewhere.
And trying to write out one of those numbers is just… unbelievable how long and how big one of those numbers is.
Did that answer?
Even the elliptic curve… it's using really big numbers And I think rather than prime.
It's using properties of this weird curve, and there are a number of different curves.
And you put… intersect that curve at a certain point with a certain vector.
You get another point elsewhere, and those are the numbers used.
And figuring out what that is, it is a super complex problem.
Go for it, Lee.
We've got a few more slides left here.
Pls does have the capability. Or it allows whatever you however you want to phrase it.
It can prevent a lot of common threats. Like, eavesdropping, sniffing traffic.
Fake websites. Yeah, uh, fishing or domain spoofing, because TLS requires a certificate check. The SSL days, you get away without it.
Data theft in transit data interception can't be done with TLS because the actual data is encrypted with an ephemeral key.
And that is only valid for the single session. Are the single request. In other words.
Every time you… pull a new page on a website.
A different key is generated to encrypt that page. Because each HTTPS request is a unique conversation.
Message reuse, replay attacks. Tls prevents it, because with 1.3, the actual data encryption isn't, as we said before, many times, is an ephemeral key. It is only valid for one particular connection, one particular individual conversation.
Um. Flag on the play.
So, in general. Yes. Uh, but eavesdropping, or specifically sniffing traffic.
I can configure Wireshark on my computer.
To sniff traffic between my web browser And my email client… using TLS 1.3, if I cause the client to save that ephemeral information.
Or if I cause the server to save that ephemeral information.
So the client or server is complicit with the sniffing. As a diagnostic aid.
But without that complicity, one side or the other participating. Yes, it is nigh impossible to sniff.
And we've been trying to get them to demonstrate that for 6 months.
Sorry, life has been very busy, and I changed jobs. In March. Um… Vashin, uh, domains with spoofing.
That has moved out of the…
Impersonating the exact same domain name and spelling. To homonyms or other attacks.
Um, data theft, in-transit data inception, or interception is really sniffing traffic again. Again, you have to have a complicit party.
But the replay and the downgrade attacks, absolutely, that is things that TLS Particularly 1.3, has gone to great lengths.
To protect, because those were some of the attacks. That could be done. And part of that has to do with was the full packet encrypted, or just part of it when Gary was asking earlier?
Getting into some very hairy details.
Yeah, and I would… and my… solution to domain spoofing is to outlaw UTF-8.
I don't allow UTF-8 in my email client. Pure F.
On the client, on the client.
You have that capability on your server, as… Fair. Um, you have the… technical acumen and willingness to do that.
Not everybody does. And it's kind of like, once encryption was out there, because in the 90s, when encryption was a munition, like, strong encryption was a munition.
I think… was it filled? Zimmerman with PGP.
He printed the code on a t-shirt. So it became a work of art.
Subject to different… exportsing.
Copyright.
Um, and it's… once the co… For… oh, thank you, free speech. Once it is out there.
Free speech.
Once the horse is out of the barn. Anybody can use it.
So, even if you… if people ban UTF-8 or 16, or whatever.
It's out there. People are still gonna use it, they're still gonna do homonym attacks.
And it's gonna be reliant on people to do things to protect themselves.
Some to-dos for John Q. Public. And also, all your relatives that you support.
Make sure their voices are up to date, and especially any browser or apps they use.
Train them to look for the lock in the address bar.
As we've discussed, that is a little… is slightly more important nowadays, because it actually means something of TLS 1.3.
Train your supportees to never… to not click on a site.
A lot of times, you can live with HTTPS only?
But if you're a techie. It's almost impossible.
I can't afford to turn it on because there's too much stuff I use locally here. Firewalls, local machines in the office.
My phones… that I have to use HTTP on.
And if you do have a choice. Prefer TLS 1.2 and 1.3 sites, but that is a pretty…
Esoteric difference that you have to know what you're doing to even see it.
In summary, SSL is obsolete and insecure. Tls is today's gold standard, version 1.3, fast, secure, and private. You're actually using it every day.
And, uh, one more comment to the… Quantum computing discussion.
I would, uh… propose that by the time your average script kitty can hack a key with quantum computing.
We will have keys that cannot be hacked by quantum computing because Our computers will have matured some not at the quantum computing rate, but fast enough to maintain a good level of security.
That's it.
Um, I'll toss out there that TLS and SSL A lot of it started… with websites.
But what has happened, particularly over the last 15 years. As the web server had the certificate.
Email servers started using it as well. And as more servers started using it, even more started using it. It gained critical mass and kind of snowballed.
So we're now seeing TLS used Excuse me, for many, many, many different things.
Far beyond web pages. I will bet you dollars to donuts.
Almost all of the communications through Zoom for this meeting. Is using TLS, probably both.
Over HTTPS for the edge communications. Probably for internal things.
I know it is being used for communications between databases and enterprise applications.
Um, banks use TLS encryption for the terminal emulator on the bank teller's computer back to… the mainframe.
Tls is… as ubiquitous, almost as ubiquitous, as TCP is.
Um, TLS is also being used over UDP.
It is massively used. Everywhere.
For a very large value of everywhere.
Should we keep an eye on our congress critters? And they… police agencies that want to have back doors.
Definitely.
Yes, we should. Um, I feel like… I personally will be able to effect extremely little influence in that matter.
But keep an eye on it.
If it ever happens, just stop using any company that allows it.
Or any service.
There's a reason my email despite being on VPS IP addresses.
Lives on VMs in my basement.
Other questions?
I want to add something that… this is Randy. I want to add something that is just a hair bit off of this, but… It does have to do with the encryption, and that is… OTA, over-the-air TV, Which, standard right now is standard…
Version 1, and they're trying to… to get access to version free. And the problem with… That is, it gives them the capability of using encryption, and encrypting the… access to over-the-air TV, which is, at this point, free.
But assuming they go to this new standard. Over-the-air TV won't be free, and it will be, um, very well encrypted.
And a little bit like satellite TV wound up becoming. Just an add-on thought.
I'm not surprised to hear that. Um.
I will say the fact that it would be encrypted does not… imply… non-free for charge.
Um, there could be legitimate reasons for encrypting, but using well-known public keys.
Or a key that could be acquired some other way. Legitimate way, approved way.
For free. Uh, much like you have encrypted Wi-Fi hotspots. If you go into the coffee shop and purchase a beverage, the receipt printer may print the Wi-Fi password on the bottom of it.
Grant, I didn't realize you were on the payroll of the Broadcasters Association?
No, I'm not. Um, and one of the… I can take a notebook.
And get better performance out of the hard drive by using full disk encryption.
Versus unencrypted. And it is a weird side effect.
Of the way full-disk encryption works. Drive access for certain things becomes faster.
Especially if… compression is, like, pre-encryption compression.
Is in play. There are… legitimate white hat.
Reasons… to encrypt things.
Um. They're a very minority compared to the less savorable… savory reasons to encrypt something.
Yes, friends, you've just heard a verbal recitation of the abstract for the talk that Grant will be doing in August or September on full disk encryption.
No, no. I've got other things to do first. Like, demonstrating turning on the option to save that ephemeral key and have Wireshark show the decrypted data.
Hey, that's been on his queue for over 6 months, Gary.
You know, you guys are nice and all, my wife trumps you.
That's so hard to believe.
She hood must be obeyed, right?
Yes, I am happily married, and I would like it to stay that way.
It's always a choice.
Yep.
I've got one more for you guys. I just typed into, uh, Copilot, how are Zoom calls encrypted? And its response was, I'll summarize was just… point one is that they're using 256-bit AES GCM encryption.
Point 2, they talk about end-to-end, but if you turn it on.
You can't do recordings online. And then 0.3 was the one that really surprised me and made me come off mute here.
It's talking about post-quantum end-to-end encryption. And I won't read everything that it says here, but they're talking about it, that apparently they've introduced it, it says.
That's just what Copilot says, anyway.
I question the veracity of that, and… would want to know more before believe in that. I absolutely believe you that that's what it says.
I have also seen… LLM-generated AI slop that is… Really?
So, I don't know.
For anybody here that would like to know more about quantum computing, the guy that does the explainingcomputers.com site.
Annually, he surveys the progress that's being made in quantum computing.
And I heard highly suggest you go to his sites. And find the stuff he's posted on YouTube, for the last, uh, 3 or 4 years about quantum computing, going back to the oldest, and watching the updates to get a better understanding of how quantum computing will
Is being, uh, working. Or how it works.
That's it. Explainingcomputers.com.
I will toss out there… An epiphany, I had a number of years ago.
Regarding encryption. My goal for encryption, be it encrypted email, encrypted web.
What have you. Is I basically want to thwart bastard operator from hell.
Or your average script kitty. I know that there are people in the world that can break any encryption I can use.
Through some myriad. I am… That is a foregone conclusion to me.
So, I think about my threat model And… I am comfortable using older encryption and older ciphers and keys… Because my goal is to be able to… relatively confidently exchange a vulnerability Report.
With something to a co-worker. Or send a password that I just set for the console for a coworker to log into something.
I just want it to be… enough that the average technically-minded person.
Cannot break it. Um… I have a litmus test I use. I do not mean for it to be egotistical.
But I ask myself. Could I break the encryption I'm using?
If I can, I probably want to use something better. If I can't, it is probably good enough for my use case.
Lee, Gary, Stan, I'm surprised you don't have a response to that.
Use locks.
Um, not… Currently, I did have looks on my VPS, posted in the cloud?
And the OS, it was not full disk encryption, it was an encrypted data file system.
And I would have to log in and open up LUX, mount the file system.
And then start services. If I had a notebook.
That I took around with me. Personally, I would use Lux.
Um, I know work has full disk encryption on my work notebook.
But the systems that I have in my life. Are within my house.
So, you either have to break in across the internet. Physically break into my house.
Or walk into my house. With a court warrant.
Beyond, and… trying to secure beyond those things becomes exponentially more difficult Does that make sense?
Oh, yes. Um… I put Lux on my laptop because I realized that it would be possible for it to get lost And if I was… headed away from the house.
And, uh, it's not… It's not difficult once to set up.
Mm-hmm.
Um, one of the things I have done with… current employer and previous employer was… We did not necessarily care about encrypting data on disk.
But there was one very profound thing that encrypted disks provided.
And that was, um… cryptographic sanitization.
And it is in… current PCI… I believe, and some relatively recent government specifications.
That if you're using full disk encryption with sufficient key length, and that key is encrypted on the disk, and you just have to unencrypt that full disk encryption key for the drive to use things.
If you erase… the on-drive key.
Now, that drive is considered cryptographically sanitized. Because there is no reasonable economical way to recover that key and access that data.
Without brute force. So, with the drive being cryptographically sanitized.
It can be reused… you know, their servers without any problem And it's less than a second.
To erase that cryptographic key. So…
The thing I like about Lux is the fact that you can have
You broke up, Stan. The thing you can have, or the thing you talk about Lux, is you can have
Multiple keys.
Yes. Um, a job I… Yes.
With Lux, you can have multiple keys. So they… so the… company could have a key, then a user could have a key.
The next user could have a key. And they could all access the same data.
Yep. Um… And the multiple jobs ago.
I actually leveraged that Against company policy.
But we had LUX encrypted notebooks. And being the… intelligent, somewhat… rule-breaking Unix admin that I am.
I actually added a USB flash drive, which was against the rules.
But, so what? To the dock that lived on my desk inside the secure room inside the secure building.
That… Pardon?
My bandwidth sucks.
My band was sucked.
Hidden, here are the last things you said.
Okay. Um… I can go into more details on In short, I had a… key on a flash drive connected to my dock.
That when my notebook booted up. It would look to see if that was there, and decrypt LUX and automatically come up.
So, while my notebook was docked. That unlocked Lux for me.
But if I undock my notebook, and I'm at home or out away from the secure environment.
I have to manually type in the password. And that was through looks having multiple keys.
Right? Well understood. Thank you.
Granted, I just have to say something funny. My wife walked by when you mentioned Script Kitty. She thought that was pretty funny, because the cat… do a lot of the typing in our house.
But I have to run, but thank… I just wanted to say thank you guys very much for doing this presentation today I just… I'm in Boulder, and I just was looking for something to attend tonight, and… went to meet up and just…
Type in, you know, click the Today button, and you guys came up and looked interesting, so thank you very much.
Well, thank you for coming, Doug. You've been a good part of the meeting. You've made a lot of good comments. Appreciate it.
And, uh, before you go, let me just, uh… I'll try to share my screen here.
Uh, our next, uh, presentation-style meeting. Uh, let's see… Absolutely no problem.
Is going to be the second Wednesday of next month, and Let's see if I can do this.
What do you want, Calder? Uh, yeah.
Doug, I lived in Longmont. Um, for about 8 years, and… I have really been missing the weather from the, uh.
Eastern slopes. Especially as summer sets in here in St. Louis.
Yeah. You guys… okay, so Grant, you'll believe this, but I don't know how many other people would believe me. I just got an email this morning from A Basin saying that skiing has finally ended for the season. They said this is their longest season in their history.
I'll believe it. That also tells me that they got a fair bit of snow, which is good, they needed it.
You're on screen. Hold on, we're gonna get this up on screen in just a moment.
It was up, and then it went away. Now it's back again.
Okay, if you go to July the 9th, I think, and let's see, here's July…
My ninth, yep. Go to the, uh… I think it's in the hour… there we go, okay.
So, Sean is going to be our presenter on July the 9th.
Uh, we usually try and make the tutorial and the main talk two different presenters and two different topics. This time, they're related, and it's the same presenter.
The tutorial's gonna be, uh, Ansible 101, kind of a Ansible for beginners.
Uh, give you the idea what Ansible can do in general, and how to get started in it.
The main presentation, then, is going to be… Ansible Pull.
Which is a particular, uh… tool. Particular way to use Ansible. Yeah, so it's a particular way you can use Ansible for this particular tool.
And, uh, so, uh… That'll be the main. So, uh… Doug and anyone else, please come back on July the 9th and enjoy Shawnstoke.
Yeah, but I will definitely see you guys. I heard about Ansible and always wanted to learn something about it, so awesome, thank you.
Cool.
One of the other things is… Sean, uh… I think he might ask for questions to be at the end, but the way we've had the dialogue tonight, Sean, is wonderful about answering questions.
Uh, some during, but more after the fact, I believe.
Anything else we should say about the calendar while we got it up?
Do a lug next month is… we don't have a topic yet, okay? We… We don't have a topic for the log yet.
Items in red. Our sponsored meetings.
By the way, Doug, this is the calendar on our main web page. You just go to Resources Calendar.
And… You can spend every night and most of the days dealing with meetings, local and remote.
And there's all kinds of interesting stuff on here.
Um, if you're not subscribed to the mailing list. Um, I started not a flame war.
But a mini rant, which turned into some interesting discussions. About Google's recent Um, extended key usage.
What they will allow or will not allow in their root certificate program going forward.
And the implications for the industry.
Does that relate to 31 July? That I've heard… In the background.
I don't recall dates for that.
No, it's, uh, 2026 is implementation. Or is, uh, the deadline, I think July 26th is the… is the… deadline, but… the implementation is… has to start this year, so it can be tested.
Now, this next year. Right, okay.
The deadline's next year, but it's gonna… Yeah.
Okay.
Um, I hinted at during the talk. There's already been some evidence of early breakage They're… the XMPP, Extensible Messaging and Presence Protocol.
Basically the… instant messaging protocol that is more than just IRC, that is not proprietary.
Uses many of the servers use certificates to authenticate to each other.
There have been multiple XMPP servers that the way they had their Let's Encrypt client configured.
It defaulted to, let's Encrypt's new profile. Which does not include client auth.
And thus, servers could not authenticate to each other. And the XMPP community is already experiencing problems, and People had to revert to older certificates.
Change their profile, issue new certificates And scrambling.
Uh, for those of you folks that are physically local to St. Louis, I might point out that the first weekend in August.
Is a sale tax… is the sales tax holiday? And if you need any hardware.
A long-time supporter that has slowed down recently. Is EPC… In St. Charles, and I do have Other locations around the country.
Where you can get a 2 or 3 old computer for a few hundred bucks.
They frequently have some nice deals, and of course, the sales tax holiday, you can save a little money.
Yeah, and if you look for Tony Lavasco, he's a good friend of ours, he's also a Linux fanatic.
And he'll give you good advice.
Are we ready for a bookend?
I think we're ready for a bookend. Oh, I guess first I should ask if there's anybody who has Just a general question, not pertaining to tonight's topic that they wanted to ask?
What are this weekend's winning lottery numbers?
There we go. About that quantum computer problem. Okay. All right, I guess we will bookend it then. Uh, thank you all for coming. This was the, uh.
June 19th, uh, Thursday, uh, 2025. Uh, the St. Louis LUG meeting, St. Louis Linux Users Group.
Uh, our speaker tonight was Grant Taylor and Lee Lamert, and they were talking to us about, uh.
Uh, how SSL has evolved into TLS. Tls. And other security… related security issue. And other security-related issues.
Thank you both, and thank you all for coming tonight. A lot of good audience participation.