Oso cofounder/CTO Sam Scott was a guest on The Hanselminutes Podcast, hosted by Scott Hanselman. With a PhD in Cryptography and being an engineer by training Sam digs into what the average developer should know about Cryptography. Listen to the 34-minute episode to hear from Sam and Scott on:
- A brief explanation on Oso
- What happens when a browser visits "google.com" from the perspective of the cryptography
- Spoiler: a lot happens! We talk about everything from: SSL/TLS, public/private key, certificates and PKIs, password hashing and salts, encryption algorithms, and session and bearer tokens.
If you're interested in learning more about Cryptography and Oso sign up for office hours with Sam, or join us on Slack!
The transcript for The Hanselminutes Podcast with Oso can be found below or over at HANSELMINUTES PODCAST by Scott Hanselman.
0 00:00:00
Hey friends, there's something new from our sponsor Text Control: Their new product DS Server provides document services out-of-the-box for all platforms and languages. Whether you want to integrate document creation, editing, sharing, or collaboration into your web app, DS Server provides the backend technology to integrate that professional document processing. For example, using DS Server, you could integrate an MS Word compatible document editor into a pure JavaScript, Angular, or an ASP.NET Core application. You can create PDF documents using Web API calls or even request electronic signatures from end users. DS Server is also hosted on premise in your infrastructure or with your cloud provider such as Microsoft Azure.
0 00:00:43
And you can test DS Server without downloading anything. Create your first DS Server application in minutes by requesting a trial token on their dedicated website at dsserver.io. That's D S S E R V E R.io.
1 00:01:13
Hi, this is Scott Hanselman. This is another Hanselminutes today. I've talked to this, Sam Scott. He is the co-founder and CTO at Oso, and he's completed his PhD in cryptography.
0 00:01:24
How are you, sir? I'm very well. Scott, how are you? I'm very well. And I'm very excited to talk to you. You know, I've been doing a class kind of an informal class on my YouTube recently called computer stuff. They didn't teach you. And I'm excited to talk to you because I feel like not every software engineer understands the things that they maybe need to understand around cryptography. Yeah, I think that's right. And to be fair, it's a, it's a large, large topic, cryptography and security in general. So let's see if we can address that. Well, you are the CTO at a company called Oso, which has a piece of the secure pie. This is an authorization service.
0 00:02:04
So you're making sure that people have access to the things that they need to and not access to the things that they shouldn't have. Yeah, that's exactly right. And you know, this is within the larger mission of Oso is really around making security, something that is easy for developers. That's kind of the whole point. Okay. So when I, when I talk to developers, when I interview them often, I'll use one of my favorite interview questions, which is, you know, you go to your browser, you type, you know, google.com or being, and you hit enter and what happens. And the joke is that well, from what perspective, like, do you want to talk about the keyboard? Is this a job for a hardware engineer?
0 00:02:44
Let's talk about how the enter key presses and metal touches metal. Are we going to be a physics person? Let's talk about the electrons and or the Bluetooth or the USB. Let's talk about you type in Google. You hit enter from a security perspective. Yeah,
2 00:03:00
That's, that's a great one. So first of all, there's, I mean, there's a, there's a piece which maybe we won't go into too, too much detail, which is, you know, the, there's a whole DNS piece of this, which is your computer's gonna affect you to look up where, where is Google to call them. What's the sub that lives out. But from, from there, you know, what's happening at your, you, you've established a connection with, with Google at home. And the first thing that's going to happen is you're going to try to stop. There's a TLS connection with Google, right? So this is a effectively secure channel where you're trying to establish that this is actually Google. You're speaking to that. You have some kind of proof that this is Google.
0 00:03:36
Okay. So I type google.com and assuming that my browser didn't use what's called H S T S, which would have gone looking for a secure connection by default, do I connect over port 80? And then I get quote unquote, promoted to a secure or redirected to a twister.
2 00:03:54
Exactly. There's a, there's a few places this might happen, but you know, most I'll say, you know, most web servers these days will automatically redirect any plain text HTTP traffic to the secure poll. It will say, no, you should go to the HTTPS. Once you go there, then you browse at noise. Okay. I I'm expecting this to be a secure connection. I'm going to, I'm going to try and stop your that.
0 00:04:13
Okay. So what does that conversation, because I know I type google.com I press enter and a lock appears. So there must have been a lot of chatter happening to make that lock happen.
2 00:04:23
Right? Exactly. So, and again, this, this may not necessarily be the case with Google and depending on the browser, but you know, in, in general,
0 00:04:29
I can use hanselman.com, whatever it makes you happy, some other column. That sounds good.
2 00:04:34
So, you know, I suppose I haven't visited hanselman.com before, right? I have no, I have no preexisting relationship with the website. I've never been there. My computer doesn't have any, any special knowledge about it. So hanselman.com is going to need to present me with a proof of its identity. So it gives me back, what's known as a certificate and the certificate says, this is how some other column, and you know this because I have a certificate proving it. And the certificate is signed by a certificate authority. So these are, you know, there's a small number of fees and that job is effectively to, to pro, to dish out these certificates to prove that they've verified that this is indeed, you know, the owner has a middle column and those,
0 00:05:10
Okay. What does that mean? That you trust hanselman.com Because you and I have shared trust with an adult.
2 00:05:17
That's exactly right. Yeah. So for example, you know, this one, there's one that's been growing massively over the last few years called, called let's encrypt, where they've established a free service for this or that, you know, there is a let's encrypt certificate authority. And actually in the past, they had their certificate signed by another one. This we're going to see this as a recurring theme throughout this entire conversation. You know, this Tuttle's all the way down kind of thing. You know, you're trusting who trusts you trust you, but in this case, you know, keeping things reasonably simple, suppose you have a certificate from let's encrypt. I trust less encrypts. I maybe have a, you know, a relatively small number of these certificate authorities. Like hard-coded on my, in my browser, on my computer that I trust.
2 00:05:59
So when, when I see this typical from you, and I can check that let's encrypt where indeed the one who, who gave you that certificate, then I'm like, okay, that's, that's good. I trust by association here. Yeah.
0 00:06:10
Okay. So I show up at the border, I have a passport. We do have to make some assumptions. I'm a human, you're a human. We are familiar with the concept of a passport. We agree that passports are a thing that can at least prove, or at the very least assert my identity. So you just said hard-coded. So my browser does have to bootstrap itself. It needs to at least know of some main top level root concepts. Like there are certificates and there's an authority for them, or at least some number of them can update that like, can, can a new certificate authority assert itself and appear in the universe.
2 00:06:46
Absolutely. And that'd be, that'd be the process that browsers will go through when they update, for example. So you maybe get a new Firefox update and maybe it comes with a new re certificate authority has been added.
0 00:06:57
Okay. So we start with that assumption. I handle the dotcom present this sort of certificate to you. How do you know I didn't just fake it or make it up,
2 00:07:06
Right? So this is where we get into the kind of cryptography piece of it. So all of this certificate authority certificates, as part of what's known as a PKI public key infrastructure. And, you know, it's all, all based around this area of cryptography called public key cryptography. And the sort of the public piece is referring to the fact that you can have this kind of pots of your, of your cryptographic key, which is, which can be public information. And it kind of provides you with some cryptographic material that you can kind of share out in the world that allows people to do this, this kind of verification operation. It's it's this like two-sided thing. So if I have, you know, so the, the key pal we made up of two parts, the public part and the private part, the private part, which would be the piece that say let's encrypt has, can be used to do a signing operation so they can sign the information that you give them and say, yes, I that's encrypted check this.
2 00:07:59
I have cryptographically signed it and put it out into the world, the public piece, which should be the piece that is downloaded and stored on your, on your computer in your browser can verify that signature cryptographically and this, you know, this public private key public key cryptography, the, these are the pieces that are all based around effectively number theory and number theoretical things coming from maths, hot problems that, that can't be sold and coming broken and use some really interesting constructions to solve.
0 00:08:26
Oh, okay. So I receive a letter from the King and it's got a cool wax seal on the back and I flip it over and I look at the envelope and I go, this is a regular envelope. And I see the wax seal and I go, wow, that's elaborate. I don't think I could fake that. I've seen that before. I trust that I know that that's the King because he made it with his ring or whatever. And I get the public part, which is the chunk of wax, but the impression in it, but I can't make it because I don't have ring. And why do I trust it?
2 00:08:57
Maths? Yeah. So maybe, you know, maybe the public part is, you know, maybe they, maybe the, the King posts, you know, puts a notices up in the, in the town square. I have to say, you know, this is what my seal looks like. You see this on a, you know, pushed into a wax seal and you can trust it. So now, you know, the wax, the wax seal hairs, maybe the signature saying that this thing is authentic. You pop open the letter and you look inside and you have the, you know, this piece that you now know comes from, comes from the King.
0 00:09:23
Okay. Now, TLS, I've heard that more and more lately. Like, I didn't think about TLS 10 years ago when I started thinking about cryptography. Now I hear about it all the time. And now I hear about versions of TLS. What is TLS and why does it need versions? And how does that relate
2 00:09:40
SSL? Yep. So TLS stands for transport security. It is effectively the evolution of SSL, which is the secure socket layer. So we, we switched over from calling SSL TLS quite a few years ago now, but they're, they're effectively representing the same, the same core objective, which is around establishing and securing a communications channel between two policies. So there are, there are two pots of, of, of TLS. There's the, the handshake protocol, which is the kind of initial piece you go through where you establish identities and you share cryptographic material, and you kind of do everything you need to kind of get the conversation up and rolling. And then the second part, which is the recollect protocol, which is, you know, once we've established our cryptographic materials, how we actually do this kind of encrypted authenticated challenge each other.
0 00:10:31
Okay. And when you say it's the next version, is it, is it a situation where we should just stop saying SSL and just start saying TLS? Or is that just an implementation detail?
2 00:10:43
That's a good question. I feel like I'd say potentially more controversial in some circles. I'm I, it's pretty common. I find to see people just write to SSL slash TLS to kind of, it will be on the same page, which one, but if you're actually using a version which is called SSL, then you shouldn't. Cause it was a very up-to-date you should be looking at using TLS 1.20 1.3. So where at 1.3 is the most recent one that was sort of standardized kind of in the last year.
0 00:11:11
So it sounds like it's a branding thing. Like when I say Kleenex, I don't necessarily mean the Kleenex brand tissue. I just mean tissue generically. So SSL is a thing that we don't use anymore. That is deprecated, but we, everyone knows what you mean when you say
2 00:11:26
Exactly. Exactly. Okay. So that doesn't sound too bad.
0 00:11:31
Well, it's a branding issue, but we know what we mean, but you're right. If you are using the original SSL, if you're using original brand Kleenex, you might want to check out some of our new tissues.
2 00:11:41
Exactly, exactly. Okay.
0 00:11:43
So then I've proven that it is in fact hanselman.com that I'm talking to, is that trustworthy? Can I trust that? And what's the difference between and trust?
2 00:11:54
Yeah. So the, the trust piece of this, everything we just spoke around about the PKI and doing certificates, this is it's used as a piece in that initial TLS handshake. I was just talking about. So w you know, when I'm connecting to Huntsman, I'll call them, I get the stiff, that's my, that's my piece of the trust. I'm like, because I trust the typical authority to giving you a certificate. And I think probably no, one's, metaled in that and done something, something suspicious. I'm going to trust what I get from you. And what I'm going to get from you in the t-test handshake is pieces of cryptographic information that allow us to establish a shed key. And so this happens through a process called a helmet, which is another piece of the kind of public key cryptography world.
2 00:12:36
But instead of being about a signature, as we just spoke about it's about establishing a shared secret that only you and I know, but nobody who is intercepting, the traffic in between can, can work out.
0 00:12:48
Okay. So it isn't necessarily proof that it is me, but it's proof that it is a quiet conversation that we're really talking just to us.
2 00:12:57
Exactly. So, yeah, by the end of the t-test handshake, I'm like, okay, I, now I now know that you and I are the only ones who have this piece of information. We can use this to derive a encryption key and encrypt the traffic between us. So this is now an encrypted channel. It's this secret channel between you and I, and only the person who I am, you know, only someone who could have gone through that whole PKI trusted Mary process would be able to have that key. So whoever that person is, you know, we have, we have privacy between us. Nobody can Snoop in on the traffic that's happening,
0 00:13:32
Why wasn't SSL. Perfect. And how do we know the TLS one point, whatever 1.3 isn't isn't perfect. Also like you're saying, all of these things are because maths, we then discover that it's not the case or an, or D or computers getting faster. Like, why is this not the final word on this,
2 00:13:53
This topic? Yeah. So sort of all of the above with what you just mentioned. So there are some of this, which is, you know, over time we are evolving our understanding of what it means to have a secure encryption between the two of us. And, you know, for example, one of the, one of the big changes in TLS, 1.3, it was around this concept of forward secrecy, which is even if someone was to Snoop in, on a, you know, encrypted connection for, you know, now for example, and then later we're able to get access to some of the cryptographic material that those servers had on hand. So, you know, the keys that we use to, to establish that initial connection, even then they wouldn't be able to retroactively decrypt and see our traffic.
2 00:14:36
So this is like something which is like a really strong guarantee that just because someone's listening now, doesn't mean they can work out what we spoke about in the past. And this wasn't something that was previously that well understood. And it wasn't something that was an objective of the earliest versions. But as you know, as the primary, the, the academic community is like on the Stein of these new notions, they can kind of start trying to evolve in, in the, in the things we design. So that's kind of one piece of it. So
0 00:15:06
In the future, like 10 years, 20 years, a hundred years, theoretically, the maths and the underlying stuff in this technology will be maybe versioned and flavored and have a little extra this or that, but are the fundamentals,
2 00:15:20
Correct? Yeah, I'd say the, the fundaments is a very, very strong, and actually one of the things that made TLS 1.3, the process of it very unique was that unlike some of the previous versions, the academic community was brought in on a very, very early stage. And, and this was something I was part of as well as being in academia at the time was applying some of the latest and greatest techniques to understanding is this protocol secure from everything down to the kind of mathematical proofs of each of the pieces to things like full methods, which is like running sort of exhaustive, computational checks on, you know, could an unbounded number of attacker who could listen into an unbounded number of clients, like find some combination of passing messages to kind of break the break, the security.
2 00:16:06
So this is very rigorous process that went through 1.3 to avoid some of the, some of the mistakes and mishaps that happened in the POS. Some of which are cryptographic involving cryptographic attacks, some of which are sort of more of a maybe implementation details or just combinations of things that were unexpected.
0 00:16:27
Okay. So I've, I've, I've secured my hanselman.com connection with you. And maybe you're going to log in, you're going to put in your username, your password, you might do it two factor auth or whatever that occurs over the top or within the, you know, the tube that is our private conversation that is secured over this encrypted connection, but the way that we're checking passwords and things, does that have anything to do with the certificate that we're talking to?
2 00:16:54
Yes and no. So not currently. So right now, what happens is I have this secure connection. So I'm, I feel, I feel pretty confident that I can send my passwords over that secure connection. And no one else is going to intercept that and look stupid on that. So I'm going to send my roll pasta to you, and you're actually gonna get to compare it with something that you stole it. Now, you shouldn't be storing my posit in plaintext because the problem with that is if someone does get access to that posit database, then you know, my possibly rich, I shouldn't have maybe have reused in multiple places is now kind of a compromised exposure to the world. So what you should be doing instead is, is storing. What's known as what's called a password hash. And the idea there is you take my pasta and you basically apply a lot of computation, which can only go in one direction so that nobody can kind of work it backwards.
2 00:17:43
It's allowing you to compare a positive you get from in the future with the kind of this, this new hashed version of it. Okay. That's what the current version looks like today.
0 00:17:53
It is important or interesting, at least as a, for an application developer, to note that the SSL and the TLS communication, the way that that's implemented isn't related currently or directly used it from the application developer's perspective on how that password hashing is occurred. Those are two different things. For example, you and I make a phone call, our medium, whether we use signal or WhatsApp or the actual planet, telephone is different from the language we choose to speak.
2 00:18:22
Exactly. And in this case, you know, we, we, you know, send over my posit and I'm like, okay, the channel is probably fine to send the password, but I'm in some sense, putting a little bit of a little bit of trust coming back to that word in, in the backend service and the other, and the other party to responsibility store and hold on, start Passard and not just leave it in the open text file, for example.
0 00:18:43
Okay. So to be able to submit a login form and enter a username and password and do those things, we are assuming a secure channel, cause we don't want anyone listening in and we are assuming that we're not storing just your, your password
2 00:18:56
In a text file somewhere. Exactly. Okay.
0 00:19:00
Have you ever wondered if you can be offering a faster, less buggy application experience for your customers with Reagan application performance monitoring, you have all the information you need at your fingertips to find and fix errors and performance problems across your tech stack down to the line of code. Regan makes it easy to monitor the impact of your performance improvements, quickly identify and resolve issues and see how your code performs in the hands of your customers, saving you time, money and sanity. I've personally used Reagan on my iOS apps and when to use your hits to crash, those crashes get centralized into one location. They get bucketed automatically. I'll get a call stack and an email with a line number where things were crashing. It felt to me that I got a gift from my customer in the form of a bug report, but I could actually solve head over to reagan.com and try it out for yourself.
0 00:19:47
That's R a Y G U n.com for a free 14 day trial. There's a checkbox when you fill out a form that usually says, remember me, and there's a joke going around the internet right now that maybe that's not even hooked up to anything. And that may be another whole podcast about is the, remember me button actually hooked up. But if they wanted to remember me, what are they remembering? Are they storing that password hash? Or are they just saying, sending up a bit that says, yep, that's that same guy again? How are they remembering me?
2 00:20:20
Yeah. So first of all, let's, let's think about what we've done so far. So we were in the initial kind of TLS piece. I was able to get assurance that I was actually speaking to say Google, but now Google saying, well, I need to know who you are. So you enter, you're using impossible ads. So we've kind of done this, you know, a little bit of bi-directional checking each other is, but because this user composites processes a little bit painful to have to do every single time, this remember me button could be hooked up to, you know, something like a, a token that could be given back to me to say, Hey, in the future to come back with this target, I'm going to give you something that means you can skip this whole process and your browser is just going to handle it for you.
2 00:21:01
Take this token. And I trust it because it's coming from myself, I'll Google rather than we'll trust it because coming from themselves that they can check it and be like, Oh, Hey, I saw you before and I know who you are.
0 00:21:11
So I saw you before, and I know who you are. Could I attack? Or could I pretend to be you by faking that? Remember me?
2 00:21:23
Yeah. So no, because the, if Google has configured it correctly, then the, the tokens that they give you that like piece of information that they give you to hold onto will be cryptographically protected. And in this sense, this is almost like a conversation between Google and itself sound logged in. I want to give Sam a, you know, there's cookies that he can come back in and log in easier. So I'm going to, you know, encrypted a piece of information saying, whoever has, this is I'm gonna give it to give it to sound now. So sound comes back. He presents this same, the same token. Google says, Oh yeah, I trust this. This came from myself. So it's symmetric encryption. And this isn't necessarily the kind of same public key thing we spoke about before.
2 00:22:05
I, I trust this. I can read that this is, this is indeed Sam,
0 00:22:08
What have I found that cookie on your disk? And then I sent, I emailed it to myself and I S I copied it into my browser, then I'd be in trouble.
2 00:22:19
Yeah. So this is, you know, kind of a big, a big concept of secure cookies in, in browsers. And there's, you know, so cookies are this general mechanism for browsers to remember information that well to store information, they have about a website that's talking to. So these can be used for things as innocuous as remembering whether you prefer to see a page on or dock modes. Right. But that doesn't necessarily mean to be secure information. I, I don't mind if you share that with other people, but a secure cookie should say, you know, this should only be, it should only be used with this website in particular. Don't go and share this secure cookie with some other website, because if that person's malicious, they could then pretend to meet me back to Google.
0 00:22:56
Okay. So then, and that's another, in the, in the chain of trust that we're talking about here, the chain of that trust is assuming that the browser can store that cookie and, you know, their, their cookie, their generalized cookie storage mechanism is a smart one. Yup. And that I would not be able to do that as easily as I just described.
2 00:23:13
Exactly. And you'll see the, the survey, you know, Google can tell the browser what kind of, how it's treat the cookie. And so you may, you maybe see this, you know, you can go into like browser developer tools and look at cookies and it might say something like, you know, same sites or cookie equal secure, some piece of information like that, which is saying, okay, yeah, don't, don't use this outside of this context.
0 00:23:36
Okay. So a cookie can, can hold anything. It's a name, value pair. And I could say, remember me and include things, but they can also in store, they have claims I could claim that I'm an administrator or that I'm in charge of something. That's where we go from authentication into authorization. Right.
2 00:23:54
Right. So imagine again, you're, you're Google and you have hundreds and thousands of services, maybe the login functionality, you don't want to have to go back to that user service and be like, Oh, tell me, remind me again, what role does Sam have in the, in the company? Oh, that's right. He's the admin. Okay. Maybe you don't have to go back and ask them that each time you say, well, you know, I'm already asking sound to pass around this, you know, this token to say that he, Sam, why didn't I also include information, say, you know, Sam's the admin of the OSA organization. I put that in that same piece of information. Now I go and visit some other, you know, Google service. And it's just saved itself a bit of work though. It's got that information though.
0 00:24:34
Now, when I've written off the authorization code in the past, I've literally written if user.is admin or if user.is in role. And then I kind of ended up making a bunch of events that describe whether or not a person can or can't do something. Yeah,
2 00:24:49
No, no judgment. That is a incredibly common pattern that I think most people out there are applying today, but it's such an easy, not the, it's not the only approach and this sort of a growing, growing area for, you know, expressing authorization as, as policies. And so that's actually, you know, what we're doing also is we're, you know, we're building an implementation of a policy engine. It's an open source policy engine that allows you to express that kind of authorization logic. That typically, as you say, as like, if an Alison nested things using a declarative language,
0 00:25:21
Okay. So if I wrote a bunch of procedural language that said, if I'm an admin and admin is a hard coded string, then I'm allowed to go and delete expense reports or modify history and do all kinds of evil things. That's a very naive and simple simplified way to do authorization. And probably not very secure here to saying that what Oso does is, is declarative. Yeah.
2 00:25:44
Yeah. So it's declarative, it's also a logic based. So it means those kinds of, you know, heavily branching logic. You know, if it's an admin do one thing, if that non admin do something else, if they're not an admin, then maybe check. So, you know, that is very, can be very concisely represented with this like logic based declarative approach where you sort of just typically write down a set of rules, like says, you know, admins can do this. You know, members can do this and then maybe the brunching hell happens elsewhere. You say, well, if the has not been followed on that path, that kind of allows you to represent it quite concisely. It also means you kind of get to write more of these sort of like higher order logic over your, your authorization rules. You can sort of pull out common pieces into reasonable logic and it kinda gives you one place to do all of that stuff.
2 00:26:25
So you, you, you write all that code in your policy file in the case of also you can cheat, right. Those, those rules and that logic over your application data. So you don't need to worry about hooking up. Oh, so geo database, somehow just kind of what happens in the app.
0 00:26:39
Yeah. That sounds like it maps. Like we've been using a lot of analogies to my mental model and how I think about security. Oh, it's like this and Oh, it's like that. So this is a way to basically almost bring the mental model that one has about how someone's allowed to do something in the system into a nice declarative clean way to express it. You know? So yeah. That's exactly right. Okay. So we've established our, our, our relationship. We've established our connection. We've logged in, we've checked our password with password hashes. We've stored some token, maybe some claims. So we've decided that I can do some things.
0 00:27:22
And I claim my dominion over some piece of technology that is cryptographic as well. So when you're checking, if I can do something, it's not just because I said it it's because the claim itself is also cryptographically significant, right?
2 00:27:36
Yeah, that's definitely right. So, you know, in this case it might be the entire, the entire token will be encrypted or something and, and various pieces often there's, you know, maybe it's a bit of a hybrid approach. So a lot of the time with something like, Oh, so what we see is that the, the various checks might be done in real time hitting the database and the application to say, well, you know, is the user in this picture organization, the sort of benefit of that approach is you can kind of make that real time check you don't, you know, if the user left the organization, but shows up in an old token and then it
0 00:28:06
Good point. Yeah. But there is a good have left the organization in the middle of the conversation.
2 00:28:10
Exactly. And this is, this is like a very hard problem to solve. And it's the, you know, the, the balance of the trade off here is, you know, passing information and token, it allows you to kind of cryptographically assert that at some point in time, this was true. And it saves you maybe doing some work in the future. But th th the, you know, the trade-off is you may be have this, this period of time where information might've changed, but you haven't got any way of checking that, okay. Yeah, this is, this is related to as well, like a whole, everything we spoke about pretty much hit today, also has this, this idea of revocation, which is, if you put some information out there and you want to revoke it, you want to say, this is not true anymore. So, you know, revoking a certificate is, you know, this, you know, this is difficult. It's no longer bad. I don't wanna revoke it from the world.
2 00:28:51
This is like a whole extra separate, complicated world of like, well, how'd you, how'd you update this? How do you, you know, for, for certificates, for example, there is a central list of all revocation. So you basically need to broadcast to the world. This is no longer valid. Everybody update your lists of revoked certificates on your browser, so that, you know, you're not going to trust this expired key. And so that's, that's the combat, this, this downside of having these, you know, things that can, can persist over time.
0 00:29:18
So I've got this end to end conversation. We've heard that end to end encryption. And everyone's talking about before we used to say, this is encrypted, and we have a little image on our, on our website, like hanselman.com and I have a picture of a lock and they go, we're encrypted by, you know, and you should feel good about that, but now we're seeing more and more websites companies, WhatsApp saying, this is end to end encryption. What does that mean to have end to end encryption?
2 00:29:44
Yeah. Well, it depends on what the Enza. So you might say end to end, meaning, you know, from, from my browser to the website, that's, you know, that's, those are the two ends that are encrypted. If I'm having a conversation with, you know, with Google, maybe it's encrypted to the Google service in the case of WhatsApp or a messaging client in general, what you probably want, or what you party me from end-to-end is between you and me, even though this is passing through Facebook servers, the encryption is happening between you and I, so that they can't Snoop in, on the traffic as posse, even though it's possibly through that service, then I'll see any of that. Okay.
0 00:30:17
When you say end to end, if you call hanselman.com, you're encrypted from your end point, your browser, to my end point, which actually isn't a web server in my, in, in the, just coincidentally in the case of hanselman.com, it's a, what's called an Azure front door or, or a, an edge server in the case of like CloudFlare, but you don't know if it's encrypted from Azure front door to my actual web server.
2 00:30:45
Exactly. So, you know, most applications, most websites on just a single homogenous system on a state, you know, running on a single computer, there's always going to be various different hops along the way. So, you know exactly in the case where you're using a CDN like CloudFlare, for example, or kind of one of these edge services you're talking about, you might have encryption happening from your browser to that server. They might do some decryption there, and then maybe they'll reencrypt it. So that it to go from, from that edge service to the, to the next hop and then so on. And so on.
0 00:31:12
Important for me to know though, like who should know that. Yeah, because everyone gets the same lock.
2 00:31:18
Yeah. And unfortunately, there's not really a good way on as a user to really know what's happening. You'll piece in this equation kind of ends once it gets terminated at work, whatever that first hop is, you, you get to your session. Cool. This is, this is encrypted and I can check the certificate. And it says, it's a, you know, it says it's a CloudFlare certificate. So presumably they're doing something with that. And then from then, you know, it enters the kind of opaque land of the, of the web server, the web application. And it's a kind of a, well coming back to, you know, it's really about trust. Again, you need to trust that the, that the, you know, the company, the organization doing the responsible things with the data. So, you know, we spoke about possible Zalia you, you know, you give them the apostle and you heard that they, they do the perfect thing with that.
2 00:32:03
It's true for any, any data you send them, are you still with them? You kind of gotta hope that they store on your credit card details, you know, encrypted in a database so that, you know, someone mentioned is compromised that piece of the database, they didn't get all your data. And if you think about the various like data breaches that happen over the, over the past years, a lot of them are, you know, they're not talking about data breaches of like TLS or the conversation you have with a website. They're talking about a very specific piece of that entire infrastructure that is being compromised, which hasn't got appropriate. You know, data privacy controls doesn't have the appropriate encryption. So really this is, there's a huge amount going on at the surface that as use it, you don't really hear about on us. It goes wrong. Yeah. That isn't kind of a bummer from a user interface perspective.
2 00:32:45
The lock, I think my non-technical parent thinks it means a lot like that. This is a trustworthy website and this is a good place. And I could put my credit card in here. And it really just means we're talking over a secure line. Exactly. And that's, and that's where, you know, things like, you know, the EU has this data protection thing, GDPR, that they kind of entered the phrase to try and address this type of thing is to go and hold those companies accountable to managing users data in an appropriate way, because that's kind of where this comes to. It ends up being a, some ways a legal thing. Know the cryptography is sort of, well, I'm sure there are a photographic approaches that would solve this problem, but it's more of a legal problem right now to make sure that we go around and hold, you know, make sure the companies do the perfect things or, you know, or it's something that we can kind of all do as, as developers, as engineers is, make sure that we've done the perfect controls in our application.
2 00:33:38
Very cool. I feel like this has been a really good overview of what the average techie or average programmer should know about what happens when you type google.com and hit enter, and you get a little luck there. This was a lot of fun. Yeah. I really appreciate you hanging out with me today. I, likewise. Yeah. We have been talking with Sam Scott. He's a co-founder and CTO at Oso. He completed his PhD in cryptography and Royal Holloway university at the university of London. And you can find him all over the internet and you can check out oso@osohq.com. This has been another episode of Hanselminutes
1 00:34:18
See you again next week. <inaudible>.</inaudible>
