 her next talk will be by the wonderful Wendy Knox Everett. She's going to be speaking to us about green locks for you and me. Cool. Hi everybody. Can you hear me? Cool. So this is going to be a little bit different than some of the other crypto village talks. It's not about encryption theory or anything. This is going to be about using encryption for your own personal domains if you have one. So pretty recently Chrome made a change. They've been driving towards securing everything on the website with TLS. And they had been labeling secure sites with a little green lock, which is where the title of my talk came from. But they just recently made an update such that non-secure websites now are explicitly labeled as not secure. They have a really cool blog post about this. This is just about, I guess at this point, three weeks ago, where they wrote about how this is part of their goal towards driving to securing everything with TLS. So TLS is really important because it's basically makes sure that the integrity of the website is preserved. I'm not going to go too much into TLS. I'm assuming if you're in a nerdy talk about green locks, you know what TLS is. But we're going to sort of dive into using this for some of our own personal domains. So this is my personal domain. I have had a website since like the early 2000s. It was just running on a Linux box that I was paying space for and I really didn't touch it. If you go look at it, assuming my DNS is not Horked, it is a super, super simple, plain HTML page. I should actually do something about it because I'm such a big TLS advocate and my own personal website is not secure. It's kind of a pain in the neck if you have like a two HTML page website on a very crufty old Linux server that you're just renting from someone. Like this is a pain in the neck. How am I going to do this without basically spending hours on it because I don't have hours to do. So I ended up getting a TLS certificate for my website and we're going to run through that quickly and then I'm going to end up spending the bulk of this time talking about email security because that's one that was actually a little bit more difficult to set up. So Let's Encrypt is probably the most famous way to do this. I'm actually not going to talk about that method because I host my website now on GitHub Pages which is free which is awesome. I don't pay anything to host my little tiny HTML pages and when I set it up they were not yet quite officially supporting Let's Encrypt so I use Cloudflare. So my DNS is over there. There's lots of other hosting options out there. You can use WordPress is another very common one. But I like GitHub Pages because they're how to GitHub account. I like GitHub desktop as a tool to push things up. This may be a little worry here. This is showing the certificate that's on my domain and it's a Cloudflare one. So I'm going to go pretty quickly through how I set this domain up. GitHub does not have the best directions unfortunately which is part of what drove me to do this talk. This entire experience was a lot of trial and error and I'm pretty nerdy. So I wanted to sort of document my path through as I did this for people to go back and try again. And if you're at GitHub I love your service. Please make your documentation a little bit more user friendly. So they have a blog post where they announced the Let's Encrypt stuff and the directions at the bottom are what I followed. They're still pretty up to date. So you start out by creating a repo and you just name it whatever your username is. My GitHub username is wendck. Then you check it out local machine. I'm a big fan of GitHub desktop. I like command lines but the desktop thing makes it very nice to see like the graphical diffs and everything. And you move over your files. You can see I have like two HTML files and a couple of images. I have like the world's dumbest website. This is one of the first like not even tricky but like slightly arcane things you have to do. You create a text file called CNAME at the root of the repo and you're going to check that in. Then we're going to go to settings and we're going to scroll down and we're going to add the custom domain. You can see that GitHub thinks that my domain is not currently working. This is why I was joking about my DNS being horked. I grabbed this screenshot this morning so I had forgotten this step. And of course it now thinks my site is not secure even though it is and the redirect is actually working. So DNS screws up everything even when you're trying to give a talk on TLS. It is actually still working so I'm not sure why GitHub thinks it's not. One of the things that chipped me up a little bit is because I'm not really a DNS person was I didn't know what the word apex domain meant. It just means a top level domain like example.com. For me it's wendike.org. And I'm talking about like apex domains and I'm like well I don't know what that is and so I don't think that I have that. But I do. So it's just a terminology that GitHub did not really particularly define very well. I thought I had like a sub-domain like www.wendike.org. But I don't because I own the domain. So they basically are going to tell you to point to this. Here's my DNS settings. I am copying their directions and putting it in. And boom I have a secure website. It's pretty cool. Although it took like 48 hours to have stuff to propagate out. But that is essentially how you use GitHub pages with cloudware. The let's encrypt setup is almost identical. You're just creating basically that C name and you're telling in the setting that this is going to be a secure one. So email spam is a big problem. I used to work in email marketing way back in the day. And kind of knew what SPF was and so forth. And I've had my domain on Google apps since it came out. And so I was kind of lazy about this whole thing. I'm like surely Google is taking care of this for me. I pay them $5 a month. I just use Gmail for my domain. I've not configured a damn thing. I'm sure they're on top of this. And then I kind of started thinking like wait, no to use SPF you have to set domain records. And I don't think Google can go set my domain records. And I was like maybe I should look into this because maybe my email is not half as secure as I think it is. Or like my email is secure but my domain could be used to spoof. And because I have a very old dot org domain it's actually somewhat valuable for spam. So I was like I should probably take care of this. And then fell down the email security rabbit hole. It took me about three weeks to get this to all work. And so that frustration kind of drew wanting to do this talk to just lay out my path through setting this up. And sort of raising awareness for people to realize that you do have to go through some of this. So we're going to do a nice jump into three technologies, SPF, DKIM and DMARC. And they all work together to keep people from spoofing your domain when they send spam. So SPF is pretty old. When I worked on email marketing from like 2002 to 2006, SPF came out I want to say maybe in the middle of that. Like it was definitely around then. This is not a new technology. It essentially allows you to publish a DNS record that says for this particular domain like for wendicay.org only a handful of IP addresses can send email. If you're getting email that is from any other IP address and purports to be from this domain, you should flag it spam. And also I'm going to publish these slides to my Twitter account right afterwards so don't worry too much about capturing the URLs. I've got a whole like an end slide of URLs for all of you too. But the problem with this is that it requires every single person who receives email to go do that look up. People are lazy. It also can be kind of brittle depending on your setup like at the IP address that is sending email changes. It can be a problem. People who send email from multiple places like if you have your company's email and then your company's also sending marketing email under that maybe through like a mail service or so forth. You have to remember to keep these all up to date. DKIM is the second part of this. It's kind of cool. We can cryptographically send our emails without doing a darn bit of work besides entering a DNS key. Gmail works very well with this. So if you're just using Google ops in your domain, they'll help you generate the key which you're about to walk through and you publish it. And these are going to work with DMARC to basically help you prevent people from spoofing because it's a little tricky. It's not actually super widely adopted yet. This is still somewhat niche. The big providers like Gmail and so forth are using it. But Joe Q mail server may not yet support DKIM. This is the headers from an email I sent myself the other day and I just pulled out the DKIM pieces of it. We can see I've got DKIM signature and ex Google DKIM signatures showing that the email was cryptographically signed. And finally DMARC, you can think of as sort of a block in report. It allows you to publish a policy and to basically see what's happening with your email. You can't use DMARC until you have DKIM and SPF set up which I didn't realize when I started this. I jumped into DMARC and I was like, okay, I don't understand what's going on here, what's happening and had to kind of back up and do the SPF and DKIM first. So this is kind of an overview of how DMARC works. Essentially the receiver is doing a lot of the work here. They basically get the email. They're going to go check DKIM the public key, make sure that this is working. They're going to verify that the SPF is set correctly. So making sure that the IP address that they got the email from is allowed to send email for that domain. And then they're going to apply a DMARC policy which is what we're going to go walk through. And then they generate reports for you. You have very nice pretty little graphs. So I've got lots of like nice red and green pictures of block spam coming up. If you're on G suite which is the Google apps for your domain thing, they have actually fairly good support. It was way better than GitHub's. And there's also this DMARC analyzer thing as a blog post that's also fairly decent that will walk you through how to do this. So this is a little bit jumping back. I mentioned I use Cloudflare for my DNS. So this is just showing that the place where I registered my domain, I am pointing to Cloudflare DNS servers and I'm going to do all my DNS settings through Cloudflare. I'm just on a Cloudflare free plan. I'm not paying them anything. And there's three different DNS records that we are going to go set up. So first, we want to generate the DKM public keys. This is basic public key cryptography. They're going to keep the private key. I'm going to publish the public key out my DNS record so anybody who gets email from me can go check it. And in G suite, you basically have to sort of hop down in through a couple of settings to get it. You would probably want to, oh, it's probably back to the key page. Check the G suite help pages before you do this because they do like to basically rebuild their dashboard and this could move. As of the other day, it was still at this location. And this is what it looks like. It's going to generate a TXT record value for you. And TXT is a type of DNS record that just allows you to publish a block of text. The name of it, as we saw, is Google underscore domain key. And the value starts with this V DKM goes out. K is RSA. We're telling it's an RSA key. And P equals that whole big long string. So I go to Cod for our DNS entry. Up at the top, there's a way to add a new record. I tell you I want a text. So for name, I put in the Google underscore domain key. For value, I paste in that whole big value. And voila, I have the first of my required DNS settings up here. So I'm not going to dive too deeply into all of the DKM tags. The only required one here is P equals, which is your public key. If you don't have that in your DKM TXT record, you do not have a valid one. All these other ones are optional. The only ones that I'm using, I believe, are the K equals RSA. And I think we have V equals. So those sort of help it figure out what type of key your public key is. So next we're going to do the SPF settings. Again, Google has pretty decent help for this. It will tell you exactly the string that you need to copy and paste into your DNS setting. You just follow their directions, copy it, paste it in. So now we have two DNS settings published. And so now we're ready to set up some DMARC domain keys. This is the fun stuff. I use DMARCian. If you have a personal domain and you don't have a lot of email volume, this is great because it's free. You're going to see later, like my super low email volume. I just don't send very much. If you're a company, it's also really cool. I know some folks who have enterprise accounts are very happy with it. You do have to pay for those but you have to be sending a significant volume of email before you're paying for it. So if it's just your personal domain, you're probably going to be fine on the free one. They make you sign up first for a trial and then they'll tell you if you can remain free after two weeks, like you're probably going to remain free. So they have a whole section that's going to walk you through how to add DMARC. These are all the DMARC options here. The PCT is going to be the percent of messages that we're going to be doing this filtering. Some people like to start out with just subjecting 10% of their email to it. I send such little email that I just immediately set it to 100%. The RUF and RUA are used for reporting. We're going to see some reporting options that I get from DMARC so I can see very nice graphs of block to email and so forth. If you're using DMARC and they will tell you what email value to put in. The P is a policy. You can be doing quarantining or blocking. I'm spacing on the name of the don't do anything, just let me see what's being sent options. There's three options there. This is my DMARC TXT record. I went to Cloudflare and I put it in. DMARC N has fairly good directions. P equals none is the don't do anything. I just want to see what's out there. It's a good one to start with. Once you have your reporting working and DMARC N has a little issue tracker and it tells you, hey, things are great. It's not flagging any issues. For me, it was flagging an NSPF set up at first. Then you can move to quarantine, flag these things as spam. Once you have that, you can move to reject which means don't allow this mail to get sent. Reporting is really fun. The RUA equals option is where you set it. You don't have to use DMARC N. You don't have to use their stuff for it. You can put your own email address in here and do your own filtering and so forth, but I'm lazy and don't want to write my own tools. I'm using the free tools. They have a really nice thing called the DMARC record wizard. My DMARC setting came out of this tool. It walks you through. It basically prompts you. What do you want to do? Do you want to be blocking? 1% of email. Do you want to use our tools or do you want to use another one? As I have been mentioning, they have really nice reporting. You could use your own email in that RUA tag. Some people who have bigger enterprises are doing that. Otherwise, if you have the DMARC N email and it goes there, it will show where email from your domain is sent from. I've had some friends who have set this up and been like, whoa, where is that email coming from? That's within our IP space and we didn't realize that was sending email. That can be kind of enlightening. Threat unknown emails that it flags are basically things that are not within your SPF and they're not following your DECIM settings. When you log in, you get this very nice domain overview. I only have one domain, my1dk.org. You can see right now the SPF and the DECIM state are all set up because I published those keys and they've propagated out. This is going into essentially a summary view that they have. You can export as CSVs or so forth. This is an older screenshot. I had one day when like 36 spam emails were sent from my domain and we blocked them. It varies immensely. Like I've seen up to like 200 and then long periods of time with nothing. The long periods of time with nothing is a little bit more common now because I've had this set up for a little while and I think that people are starting to decide my domain is not worth spoofing anymore. But it's really fun when you are getting spammed. You can dive into the IP address space, look it up, see what country it is. It's very interesting. I lost a lot of time just poking at it because it was fascinating to me. The detail viewer, this is from that day with a ton of spam. You can see also I'm a very light email user. I sent like four emails on those days. This is well within the range of demarky and free. I could probably like quadruple or more my email. Sending volume and be quite fine on the free plan. This is what it looks like now. I've sent two emails over the last week. Everything's green. Nobody's trying to spoof me. Life is great. Demarky and issues tab under monitor is super helpful. I took screenshots and I was trying to set this up and I lost them on my laptop so I don't have anything to show you. But it would be a little like your SPF is screwed up, go fix it, a message which I found incredibly helpful. So if for no other reason than for that I recommend you use demarky and if you're setting this up. So finally I just wanted to touch on a couple of other things. I am the world's biggest advocate of outsourcing your email. I did email. It's ridiculously complicated. I remember getting pages at 4 a.m. when things went wrong so I do not want to do this anymore. But I have some friends who for whatever reason like to run email servers in their basement. So if you're that type of crazy there's two things I wanted to flag for you. MTA strict security basically allows domains to require TLS encryption. It's an interesting setting. Start TLS also allows your mail server to protect against downgrades. They're building a list of basically servers that are going to do this and it's basically going to be like what happens with the web with TLS. You can say no I only support TLS. Like please do not ground downgrade me. And so finally I have some slides or some URLs for you here. Aaron pointed out that the FTC has a really helpful report on why you would want to use these email encryption settings. If I haven't convinced you like blocking spammers is fabulous. You can go read about the FTC. These how to explain SPF decim and DMARC are really helpful because I had to go very fast over them. And so cool that's the end of my talk. Thank you for coming.