 Next up we have Carl Kosher talking about enabling HTTPS for home network devices using let's encrypt. Alright, thanks. Uh, so I'm Carl Kosher. Uh, I'm a research scientist at the University of Washington doing wireless and embedded system security. Uh, I'm going to talk about, uh, some of the challenges of, uh, using TLS on home network, uh, devices or other internal network devices and, uh, a way to, uh, easily issue certificates for these devices. So why is TLS important? Uh, isn't, you know, WPA on your network enough? I mean it's already encrypting and authenticating your communication. Well as it turns out, browsers are really pushing for TLS these days. Um, Chrome and some other browsers are now requiring TLS, uh, to use certain powerful APIs, um, uh, such as, um, accessing the user's, uh, web camera or running service workers or pushing notifications. And so if you want to, um, write an app that uses these, uh, what they call powerful features, you need to serve that over TLS. And the problem with that is if you want to make a web application that uses those features and also communicates with local network devices, you can't really do that because it also blocks, uh, cross origin requests, uh, from a secure origin to a non-secure origin. Um, and so to make this, uh, a bit more concrete, I was trying to write a app for the Chromecast which requires applications to be served over HTTPS to connect to this HD home run TV tuner, um, so that I could watch, um, uh, TV channels, uh, on my TV through my Chromecast, um, while it, it connects to the TV tuner and pulls down the, the impact stream. The problem is that, um, so the Chromecast can easily discover the HD home run device, it gets its IP address. However, because the HD home run device only speaks HTTP, it can't actually do that cross origin request to get that, uh, impact data stream. And so this is sort of the problem that really, um, uh, caused me to, to look at this issue. So why is, uh, doing local TLS hard? Well, uh, as I alluded to, um, local devices are often discovered by their IP address and not by a particular host name. Uh, TLS certs on the other hand are issued for specific host names. So, um, in the common name or the, uh, subject alternate name you have a list of, uh, fully qualified domain names that a certificate is valid for. And, um, so if you're just connecting to an IP address, uh, that doesn't match what is in the, the certs. Some, uh, device manufacturers will, uh, ship a cert, uh, on the device, uh, and that certificate is the same across all devices. Uh, however, that can be easily abused. Um, if you might remember the SuperFish scandal that happened several years ago, basically, uh, this software, uh, pre-installed a, uh, certificate, um, that was, uh, used as a CA certificate that could, uh, sign, uh, any host name, uh, whatsoever. And the problem there was that the private key was shared across all laptops, and so anyone with the SuperFish software could then create, uh, certificates for any domain name. Um, so you can also do that, uh, when you have shared certificates across these network devices. Uh, even if you do unique certificates, again, because you're, uh, discovering these devices by IP address, um, they will often be for a common host name, like, uh, router dot homeland dot com or something like that. And so if you have any of these certificates, uh, you can get them re, you can, um, basically use those to, uh, do manual middle attacks on, uh, on that domain name. Um, if you want to do something with, like, let's encrypt, uh, the problem there is that a lot of end users typically don't own a domain. Uh, I imagine most people in this room probably do, but, uh, real users don't. Uh, and so there's not really, uh, a domain that people can use to, uh, get their own certificate. And finally, even if they do have their own domain name and they want to get a domain with let's encrypt, uh, these local devices aren't externally facing, so the typical way of using cert bot to automatically generate these certificates, uh, doesn't really work because, uh, let's encrypt can't talk back to the device to verify, uh, domain ownership or control. So it turns out that one company has actually solved this issue and that company is Plex. So Plex is, uh, well it's a little sketchy, but it's basically, uh, Netflix for your own, uh, home media, um, server. And, uh, the way that they solved it is they issue each server a 16 byte GUID and then Plex issues a wild card cert for this GUID dot Plex dot direct. And so whenever you want to talk to your Plex server on a particular IP address, you go to IP address dot GUID dot Plex dot direct and they have name servers set up that automatically resolve that, uh, directly to a dot b dot c dot d. Now this seems a little weird, but, um, the key here is that by going to that fully qualified domain name instead of an IP address, um, the, uh, fully qualified domain name matches with the wild card cert that the server has, uh, and then the connection is trusted automatically. And so this allows for, um, uh, friends to connect to your server over the internet, even if you have a dynamic, uh, IP address from your ISP, it also, uh, lets you connect directly, uh, on internal, um, like 192 dot 168, uh, IP addresses as well and everything is, uh, nice and secure. So Plex partnered with a certificate authority to issue these certs. And that's kind of costly and, uh, most IoT vendors won't bother doing this. So I was wondering if we could actually use Let's Encrypt, which provides free certificates to do this. And as it turns out, you actually can. So let's talk a little bit about how Let's Encrypt, uh, automatically issue certificates. So they use what's known as the ACMI protocol, the automation, uh, automated certificate management environment protocol. And this is implemented by, uh, a client called CERTBOT and by, uh, CA software called Boulder. And this is a way to, uh, basically automate, uh, domain validation to prove that you have control over a domain that you want, um, a certificate for. Uh, so the way that this, that the ACMI protocol works is that the certificate authority issues you a challenge, uh, to prove, uh, control over a domain that you want a certificate for. And there's a couple of different types of challenges. Uh, the two main ones right now are HTTP01, where the, uh, certificate authority asks you to create a file at a specific URL with, uh, specific contents and it verifies that you put that file there. And if you did, uh, then you have control over that domain and they give you a certificate for that. There's also DNS01 where you add a text record, um, for the domain name, uh, with a specific contents, uh, um, uh, secure token. Uh, and, uh, this is the only way to get, uh, wildcard certificates. Um, but it's nice that they do, uh, give you wildcard certificates now. Um, so for accounts, um, basically they are associated with a public-private key pair. Um, you're the, so you automatically generate this private key, um, and derive the public key from that. And that public key is essentially your account ID. Now they do have sort of an internal account ID that you actually use, um, for efficiency and other reasons, but basically your account is this public-private key pair. And you use this private key that you generate yourself to sign all requests, including the initial registration with Let's Encrypt where you tell them that you agree to the terms of service and, and so on and so forth. Uh, so my proposed solution for, um, using Let's Encrypt, uh, for local devices is, um, this service that I'm calling TLS MyNet, which lets you issue wildcard certificates for sub-domain that is tied to your Let's Encrypt, uh, account public key. So tying the, um, the sub-domain to your Let's Encrypt account, uh, basically lets you verify legitimacy at an application level. Um, so, uh, you know that you are always going to talk to your server at a particular sub-domain. And as long as that sub-domain matches, you know that, um, the private, uh, that at least someone with the corresponding private key, um, proved, uh, that they had that private key and they, um, got a certificate for that domain. So the basic way that this works is you use, uh, Let's Encrypt, um, as normal, but, uh, instead of proving, um, control over your own domain, you ask a third party, uh, to, uh, prove control of a sub-domain, um, and, uh, that third party then, um, solves that challenge for you by creating that text record. So the way that this works is the device initiates a sub-domain wildcard certificate request with Let's Encrypt. Let's Encrypt says, okay, here's a DNS challenge. Uh, the device then sends that challenge request to TLSMyNet. This request is signed with the public key using, uh, JSON web signatures. Uh, the thumb print of the corresponding public key, um, is used as the sub-domain. Uh, and because of limitations of DNS, we actually have to encode this as a base 36, which is kind of icky, but, um, it, it works. Uh, and basically the, the public private key pair here is the same, uh, public private key that is tied to your Let's Encrypt account. Uh, so this is currently implemented in, uh, two Python scripts, um, uh, that are on GitHub right now, and I'll, uh, give you that URL later. The first is, uh, dnsserver.py, and this does two things primarily. One, it resolves, uh, that, uh, IP address dot thumb print dot TLSMy dot net two, that IP address. Um, so it, it handles that for you. The second is that it also resolves these, uh, text records, um, that are used for, uh, sub-domain, uh, verification with Let's Encrypt. Uh, it uses this library called dnslib, which, uh, lets you easily create, uh, dns clients and server, servers, uh, using Python. Right now the server is sort of, uh, single threaded and synchronous, and so there could theoretically be some performance issues, but, uh, I'm planning on migrating that to, uh, Python's async IO, uh, fairly shortly. Uh, the second half of this, uh, system is the, the web server, which receives these requests, uh, for creating these text records to respond to these challenges. Uh, this does use async IO, so even though it's single threaded, um, it can handle multiple requests, and while it's waiting on one it can service another. Uh, and it uses, uh, also this, uh, JW Crypto library for doing, uh, JSON web signatures and, and JSON web keys and things like that. And then in between, there's just a standard Reddit server that's a temporary, uh, key value store for storing, um, specific text records, uh, for specific subdomains. Um, and those, uh, those last for five minutes. Um, and so the nice thing here is that really there doesn't need to be any state that you actually store on this server. Uh, you just need the, the key value store long enough to, uh, do the domain verification. Um, you don't need accounts because, uh, those are automatically proven by using the public, uh, private key pairs. Uh, and, uh, you know, the resolving an IP address, uh, is, you know, straightforward. So currently this is still, uh, a work in progress. Um, there is a test client right now, uh, on GitHub that, uh, sends a, uh, request to create a challenge, um, to the web server. Uh, it, it could be better, um, but you know, hopefully that's coming soon. Um, I am planning on integrating this with Serpbot as a plugin. However, there's a, a little, um, issue there where the, uh, Serpbot plugins don't automatically expose the account, uh, public and private keys to, uh, the extensions there. So that's a little issue I'll, I'll have to work through. The server currently has a little brokenness with case sensitivity, but, but I'm gonna fix that today. Um, it, uh, I have tested it and it does work. And as I said before, uh, the DNS server will be modified to use, uh, async IO for a bit more performance. Um, so the code is up right now on GitHub, on, uh, github.com slash supersat slash tlsmy.net. Uh, so before I, uh, finish this talk, uh, might want to talk a bit about the risk model here. Um, this seems a bit, um, non-standard and you might have some concerns about this and, uh, I'll just talk, uh, a little bit about those. So the third party domain that you use, uh, in this instance, tlsmy.net is, um, assumed to be trusted because they can always prove, uh, control over, uh, that domain in any of its subdomains. Uh, but the way I envision this being used is that, uh, each device manufacturer runs their own service for this and you're already trusting that manufacturer anyway. Um, so there, there's some sort of implicit trust there. Um, also as of, uh, fairly recently there's these things called certificate transparency logs where every certificate that is issued is, um, uh, appended to these, uh, append-only logs which, you know, block train, whatever. Um, basically to, to prove, um, or to, basically to, uh, show that certificate authorities are not issuing certificates that are unauthorized. So if you're concerned about your, uh, third party domain provider, um, issuing a certificate, uh, for your subdomain or issuing a wildcard cert for the entire domain, you can go through and search these, uh, certificate transparency logs to make sure that they are, uh, doing the right thing. Uh, so my plan is to release, uh, TLS Minet as a public service, uh, and, um, you know, get this idea out there perhaps, maybe get, uh, let's encrypt to, to support this natively and do the same DNS resolution, uh, and challenges that, um, uh, that we support right now. Um, I'm mostly see this as sort of a proof of concept service, uh, to encourage, uh, TLS adoption for these local network devices, um, that, uh, are currently hard to get, uh, TLS certificates for. And, uh, please, please, please bug your manufacturers to, to support TLS. So even if you have, um, these certificates, you know, these devices still need a way to, uh, load these certificates into them, uh, and actually speak HTTPS and, and TLS and these things. And even if you do get a certificate, uh, the device still needs to talk TLS. Um, so in summary, I would say, you know, going forward, TLS, uh, is absolutely essential for, uh, these innovative web applications. Uh, browsers are demanding it. Devices like the Chromecast are demanding it. Uh, basically you need TLS if you want to, um, use a lot of these new powerful features. Um, currently they, uh, these TLS certificates are difficult to acquire for, uh, these internal network devices for a bunch of reasons that I talked about. Um, but I, uh, have proposed here a way of, uh, easily getting these, uh, wild card certificates, uh, using a third party service. Uh, so with that, I'd like to, uh, thank you for your attention. Uh, this is my email address, my Twitter handle, and the GitHub account for the TLS My Nut service. So, thanks. All right. Thank you Carl. If you have questions, please come up and line up by me. Did you have any problems with running into, uh, DNS needing a CAA record? So we, uh, no, so we do not return CAA records for that. We could return CAA records for that, but, um, the, so for people who don't know, the CAA records, uh, basically, uh, say, or they tell a certificate authority which CAs are allowed to issue certificates for a particular domain. Um, we currently don't, uh, return any CAA records. So theoretically any CAA could issue, um, uh, certs for, uh, TLS My Nut. Um, I, I could add it. Other questions. All right. Well, then let's give Carl one last big round of applause. All right. Thanks. Thank you Carl.