 Next talk is going to be by Mike Zestman. So let's give him a big hand, please. All right, thank you very much. So yeah, this talk is about, what's it called? Oh yeah, criminal charges not pursued hacking PKI. So there's been a lot of talk about SSL in the media recently and pretty much ever since last summer when Dan put out his big DNS flaw and all of a sudden it was very easy to become a man in the middle for a large portion of the internet, if not even just a local network. So what this talk is going to be about, it's about the web application flaws of certificate authority websites. So certificate authority websites like your verisigns and your thoughts, I mean that's where you go. When you need SSL for your site, you have to go to one of these sites and it's their job to make sure that you're who you say you are and that you're authorized to get a certificate for the domain that you're requesting for. Obviously we can't have people going around claiming to be PayPal and saying yeah, give me a cert that all major browsers will trust as me being PayPal. So that's what we're gonna talk about. Now why do I feel like we need to have this talk? Well I think CAs need to be held accountable for their lack of security as we've seen over the last year since a lot of people have actually started looking at SSL as a target. Because the main problem is when CAs are successfully attacked, if you own a CA, or you somehow gain a CA's validation mechanism, the CA doesn't really hurt, because in fact they might even make money off the deal because you're just buying a certificate from them. But the people who are gonna suffer are users of the internet, the people who trust that CA. And unfortunately nowadays we don't really make those trust decisions on our own. We kinda just use a browser and for the most part most people will just end up trusting whoever the browser trusts. So what I hope you guys take away from this presentation, we're gonna talk about SSL rebinding which is a new technique. I don't know how many people were at Black Hat, I don't know, raise your hands, another couple. How many of you came and saw my talk? All right, how many saw my demos fail epically? Okay, so we're gonna go over SSL rebinding which is a technique that we use to bypass extended validation SSL which is the next generation of SSL. But I think the technique can be used for many more applications than just EV. And we'll talk about that in a little bit. Really I think this talk is focusing on general web application security awareness. So if you're either a web app pen tester or maybe you're in charge of some web applications or websites, hopefully you'll take away some valuable information from this based on how these CA's are failing to secure their own web apps. I think most importantly what people should take away from this talk is a higher scrutiny approach to SSL PKI. Maybe we really shouldn't be just trusting whoever our browser trusts. Maybe we need to look in that Certificate Authority Store and see that we're actually trusting certificate authorities from all over the world, not just Verisign and the ones we know of but some random certificate authority in Hong Kong or wherever it may be. So a little bit about the title of this talk. Criminal charge is not pursued. So last December, and the way I've been doing this kind of research, it's been on the side and my wife hasn't been too happy about that. But I've been looking at random certificate authorities and seeing how they actually process certificate signing requests. And I stumbled upon the StartCom site and I found a pretty critical vulnerability in their validation mechanism that we're gonna cover in detail coming up in a couple of slides. But one of the things they did is after the event, or the critical event, they published a report based on everything that they saw from their perspective in which they referred to me as the attacker, which was something I'd never really been referred to in the third person before. And they also pointed out that they were not pursuing criminal charges, which made me very happy. But I do wanna say thank you to StartCom because they're actually on top of their game and they fix this bug very quickly. So I mean, it just says that these guys care about PKI first and not the money, which I think is something we need to really think about. It can be very easy to just get on the CAs really hard because, well, essentially they do have a license to print money. But there are some people out there who do value the trust. So just to kind of go over the background a little bit, why SSL in the first place? Well, like I said, last summer Dan Kaminsky came out with his ubiquitous DNS flaw, affected everybody. All of a sudden you can very easily become man in the middle for arbitrary domains. So obviously if you control DNS in any fashion, whether it be through some sort of DNS exploit or running a rogue wireless access point or compromising somebody's DNS server, that can happen any number of ways, you become man in the middle. And there was a discussion on the Daily Dave mailing list which I think Halvar Flaki said, well, this is why SSL was invented. SSL is put in place to ensure end-to-end trust so that I know that my data going out on the wire is encrypted and I have a good assurance that I know who I'm actually talking to. But DNS is just one thing. I mean, we still have ARP spoofing, insecure wireless networks and all that. So I think SSL is a target, regardless of whether or not you can man in the middle half the internet. If your target is one guy who happens to use an insecure wireless network at the neighborhood cafe every day, these techniques are still gonna be of value to you. So a little bit more about SSL PKI in general. Last summer when I started looking at this, again, I was doing the talk on SSL VPNs at Black Hat. So SSL was kind of a big part of that. Cumminsi came out with his vulnerability and I said, well, how hard is it to get an SSL certificate for a domain that you don't control? And it turned out to not be very difficult. I had one within a couple of hours. But moving forward from that, I started looking at SSL in general SSL PKI and you start to see that there's a really big attack surface involved in this technology. It's not just SSL clients and SSL servers, but it's the certificate authorities themselves. It's the crypto APIs that we use to generate our key pairs. It's the browser, it's the SSL VPN client and the indicators it shows to a user. All of these things are subject to attack. And it actually branches out very quickly. I haven't touched this one in a while, but already I know there's one certificate authority threat in the middle, it's kind of hard to see, but it's the weaponized CSR, Certificate Signing Request, which if anyone sat through Moxie's talk this morning, that's essentially what he had, a crafted CSR that will end up causing a certificate authority to give him a cert that's pretty much valid for any domain name. So the SSL threat model I think is, I like it, I'm gonna put this out on the internet up on my blog. I think it's gonna change over time, but I think it's pretty cool that you can pick any one of these nodes on this tree and say, all right, well, I'm gonna go after that. And unfortunately for everyone, it seems like a lot of these attacks and threats can actually be realized. So a little bit more about the SSL track record. So I said before, one of the core goals of SSL is actually to protect data in transit. So we know when we put our bytes out on the wire and they're traversing untrusted networks over the internet, that random people can't just sniff our packets and see what we're talking about. And that works pretty well. Implementation specific bugs aside, like we had the Debian pseudo random number generator bug where a large number of keys turned out to be very weak and we had some crypto attacks. But aside from that, for now, this is working well. One thing to note about this is encryption is free. Anyone with a crypto API can generate a key pair and start communicating using SSL. But then we also have site validation, which is another key component of SSLPKI. That's where we start talking about trust. And this is why when you go to a certificate authority, you have to pay them a little bit. This is their business. You give them a CSR, you pay them some money. They try to validate that you're authorized for the domain you're requesting a cert for and then they give you the cert that's trusted by all the browsers. But when we talk about site validation, well what does that mean? That means that when you're going to a website, you have a good degree of assurance that you know who you're talking to. If you're trying to talk to bankofamerica.com, SSL is supposed to let you know that you're really talking to the real Bank of America web server, not bank-america or bank-of-america.com or other sort of variations on the name. But what we see is that well over a decade, I think Verisign actually came out with a press release last week saying in 14 years they've done or they've sold 4 million SSL certificates and that's just Verisign. But well over a decade of profits has not yielded adequate phishing prevention. I mean we're still dealing with phishing attacks in spite of SSL. And as Moxie has shown us, now we have things like null byte injection attacks in our certificate signing requests that offers a whole new attack vector allowing attackers to kind of exploit this trust. One of the things though to combat phishing that certificate authorities and web browser vendors have come up with is called EVSSL or Extended Validation SSL. They kind of work together in an organization called the CAB, the CAB Forum which is a certificate authority slash browser forum. And it's like a non-profit like industry group where the browser vendors and the CAs work together to try and make progress. What they came up with and it's been out for a couple years, it's not widely deployed but there are sites out there using it. I use Bank of America, they use EV. Or these EV certs. And essentially what EV is compared to regular SSL which we've had for 14 years now at least is that to get an EV cert requires rigorous offline validation process. This means you're showing your articles of incorporation, you're getting documents notarized. Essentially it's not an automated process. It's not fill out a form on a web app, click a link and get a trusted certificate. Which is exactly what we have with DV or Domain Validated SSL which I'll just refer to as regular SSL from now on because it's easier to say. But essentially so what's the difference between an EV SSL certificate and a regular SSL certificate? Well in this screenshot you see that we have this, we're connecting to paypal.com and we have this green badge right next to the address bar. When we click on that green badge we actually see identity information about the legal identity of the organization running www.paypal.com for that connection. And that's what we're gonna talk about in another slide. But essentially the idea behind EV SSL is to give your typical end user a very easy method of quickly recognizing what site they're connected to and then making a trust decision based on that identification. Now what a lot of people are saying now in light of some of the research that I did with Alex Sodorov and that people have done before us like Colin Jackson and Adam Barth is that EV is only supposed to prevent phishing attacks. It's not supposed to prevent man in the middle attacks. But like I said in the previous slide there are two things that SSL in general is supposed to do. Number one, protect our bytes on the wire, make sure it's encrypted. And number two, site validation. Give us some idea of who we're actually talking to so that we can trust them. And I think the idea that EV SSL is only supposed to now all of a sudden fix one of those problems, the site validation and not protect against man in the middle attacks is flawed and a number of steps backwards. Just another couple of technical notes about EV versus regular SSL is that you could install your own certificate authority cert inside a browser inside a certificate trust store. And all of a sudden any regular SSL certs that you create and sign will be trusted by the browser meaning you're not gonna get warnings and popups all over the place. With EV that's a lot different. The EV root certificate authorities are actually hard coded in the web browser. So you're not gonna be able to get your own EV root into IE, you will be able to get your own EV root into Firefox if you jump through a lot of hoops write a lot of code and compile your own version. So EV is kind of the next generation of SSL but we still have DV or regular SSL and we still trust both of them. So what I'm kind of focusing on right now because the EV certs you have to like I said jump through all these offline hoops you have to talk to people on the phone and fill out paperwork, talk to lawyers all this nonsense from my perspective but getting a DV certificate is still rather easy. It's still for a lot of certificate authorities an automated process. So just to kind of step through that I don't know maybe a show of hands who here has ever purchased an SSL certificate from a, okay maybe about less than half. A more detailed question how many times have you done that in a year more than once? All right the numbers go down. So it's not a process that we do regularly. So that's why I think it's good to kind of step through the process of getting a DV cert. So the first thing you're gonna do is use your crypto API I use open SSL. You generate a private key and then you generate a certificate signing request or a CSR. The CSR contains the public key the other half of the key pair. You then go to a certificate authority and one other thing when you're creating that CSR that's when you tell it what the CN common name or the domain name that you're looking to secure is. So if your website is www.bank.com you create the CSR with the CN at www.bank.com. Then you go fill out the CA order form with your billing information enter your credit card paste the CSR in hit submit they start processing your order with domain validated SSL or regular SSL the way they determine that you're really authorized for that domain www.bank.com is they'll send an email containing a secret a password of sorts to a specific email alias at bank.com. Now you as a person who's actually placing the order typically you have a choice you can say which alias you want that email sent to and obviously if it's legitimate it would be an alias that you have control over you can go check that mailbox get that secret click on a link return the secret and thereby you show the CA that you really are authorized for that domain because you have control over this particular email alias. At that point once you confirm to the CA that you have the secret you are who you say you are they issue the certificate. Now I don't know about you but email isn't really all that secure. So there are a number of methods intercepting email sniffing bites on the wire obviously this stuff is going out plain text there's no encryption involved so really anyone kind of downstream of the certificate authorities SMTP server could possibly get that secret and theoretically get an SSL certificate for a domain which they're not authorized for. Another important thing to note is that it's pretty easy to game these certificate authorities they're not really gonna be able to tell in fact who you actually are. So I'm gonna talk about how I got some certificates for domains I don't control at the end of this presentation but I did that using a completely fake alias and a cash credit card here. These are gift card that I bought at CVS. This was the first time I actually ever kind of went down that route of coming up with my own alias and really trying to do not reveal my own identity and the one fatal flaw in my plan is that when I picked up the cash credit card I didn't check the expiration date on it and I actually bought one that was expired. So the right side screenshot is when I went back because I paid 100 bucks for this thing and now I can't use it for anything and apparently nobody ever does that so nobody knew how to actually exchange this credit card and in the end they wanted my real driver's license too which you see blurred out there on the CVS counter so that was epic fail number one for the month of July for me but just remember check the expiration date and once you get your cash credit card with your assumed identity you can pretty much go to a CA and get a non-attributable SSL certificate. On the back, the question was where is the expiration date on the cash card? You can actually view it, it's in small print near the barcode, it's there. You just gotta know to look for it. Some of them are stamped. Some of them are stamped, okay. All right, so with that we're gonna go into a demonstration, a live internet demo that failed horribly at Black Hat but will not fail now of SSL rebinding and what this attack shows is that if you get a DV SSL certificate or a regular SSL certificate which is subject to all sorts of technical attacks on certificate authority websites you can reach a quality with an EV cert, one of these certs that's really hard to get and get that green badge or that green glow in the address bar that users love and trust so much. So with that, all right my resolution got a little out of whack but we can. So here in my XP workstation this is our victim and right here in this shell this symbolizes or this is actually the man in the middle. So the VM is connecting through my host OS and I'm using IP firewall rules on OSX to reroute traffic. So we'll start our proxy here. All right, the proxy is running starting evil PayPal SSL proxy. And type in HTTPS. Okay, we see SSL rebinding, a new connection and now we see in the main window here that we see PayPal, we see this green glow. If I click on it it says it's run by PayPal Inc. So now we'll actually log in. And two things you need to look at here. Number one, I want you to look at the green bar. It's kind of hard to follow both things but then we'll also see some really interesting information show up in the shell coming through the proxy. Now remember the green glow means that you're connected to PayPal. That's what it's supposed to mean. This is an SSL connection that no one in the middle of the web browser, in between the web browser and the web server should be able to look at your data. We'll click log in and we see my username and my mass passwords show up in the shell. Now right now if you look at it, the green glow went away and then it came back. So now we're still logging in. We see some more information over in the shell now. We see that how much money is in my PayPal account even though we have the green glow. So what we've done, what SSL rebinding actually is, is it's an active man in the middle proxy that's saying okay for this TCP connection where you're requesting the login page, I'm gonna let you terminate SSL with the real web server and the EV SSL certificate. And thereby showing the green glow in the web browser. User thinks everything is fine. They see the green glow. This is new super duper SSL. There's no way I'm gonna get it hacked. But then on the next connection which actually happens when I enter my username and password and press login, that causes the browser to send a post request. We create a new TCP connection that goes through the man in the middle again. This time the man in the middle says okay, don't terminate SSL with them. Terminate SSL with me. Here's my DV or my regular SSL certificate that's trusted by your web browser which was very easy for me to get by hacking a CA website. The browser says okay, that's fine with me. Terminates SSL, sends the bytes over the wire right through the man in the middle who captures all your data in plain text. That goes through to the, or the man in the middle actually captures that data at this point. And instead of actually proxying it to the real web server, he keeps it and sends a redirect request down to the client causing the client to send that request again. And this time when the client sends a request, the man in the middle says okay, terminate with the real SSL server, with the real web server EVSSL and bang the green glow comes right back with no prompt to the user. The only way a user would know that anything is going on is if they see that the green glow goes away but that could just be normal behavior to begin with. So that's an SSL rebinding attack. And that was the SSL rebinding attack that failed horribly at Black Hat, so I'm glad it worked out this time. All right. So move along at 25 minutes left it looks like. So one thing we need to know about SSL rebinding is that we need to man in the middle every other connection, typically when you're man in the middleing anything, you think I wanna get everything but really in a web browser session or a web application session, you're only gonna need either the username and password or maybe post authentication actually capture the user's session cooking. So what would happen if we tried to man in the middle every TCP connection and terminate with SSL and then redirect the browser as we get stuck in a loop and the user would never see the green glow. So we came up with a very simple solution for this and that's simply to count each connection coming out of the client and alternate. You're not guaranteed to get every request but if you miss the username and password, well then you're gonna get the authenticated session cookie later on. So it works very well. In reality you only need to capture one HTTP connection. The other interesting thing that I think was kind of novel about this attack is that you don't need to use 302s all the time because sometimes you need to intercept a post request and you need to get the browser to resend the post data. So you can do that two ways. You can use a 200 response, send down an HTML page with some JavaScript that redirects the browser with a fabricated form using all the data that was captured by the man in the middle or you can send down a 307 which is a variation of a 302 which tells the browser to replay the post and send the post data. There were some interesting things there. Firefox would obey the request but it would prompt the user and say, hey, this website wants us to replay. Should we press okay or press no? IE would do the same thing but without the prompt. IE would replay the request. This is IE7 I'm talking about. The interesting thing though is if the URL, the original URL that the browser posts you and the redirect URL are the same, there's a bug in IE that wouldn't send the post request data. So you need to kind of fudge the URL on the request, make it look different to the browser. You can do that very easily by just putting a hashtag on the end and it worked. And with that, there's no JavaScript required. So that was kind of one of the things we wanted to accomplish. So that's SSL rebinding, that's what you do or one of the things you can do when you get a regular SSL cert illegitimately or however you get it. You can use it to spoof an EV SSL session. So now okay, how do we get these regular SSL certs? Well, CAs use web applications. Anybody here heard of OASP, the Open Web Application Security Project? Well there's a whole big industry and a lot of money going into web application security. And unfortunately it doesn't look like certificate authorities spend a lot of their money on web application security. Which is kind of funny when you think that maybe everybody here who's purchasing SSL certificates for their websites that they're trying to secure is relying on a company that might or might not actually care about the same thing. So here on this screen we see a screenshot of obviously an EV SSL protected session with Komodo CA with cross-site scripting on it. I call that EV XSS, Extended Validation XSS. This way you know exactly which site is getting XSS. This is another screenshot from some other kind of random small mom and pop CA trustlogo.com where you can validate other people's SSL certificates and they themselves have a security pop-up because they're using SSL improperly. Trustlogo.com. Let's see, here's another one. Same site, some kind of verbose Oracle SQL error message. Possibly some SQL injection going on there in a post request. Some more EV SSL protected CA shenanigans. Here we have a default service exposed. It's the access web service, something or other. I think it's from Apache. Same website, here's their WisDL. XSS.com, here's about, I don't know, six different VeriSign URLs reported to XSS with XSS in them, most likely also protected via EV SSL, latest and greatest. Here's a small CA that nobody's probably ever heard of. They're actually based out of Spain somewhere and they have a whole bunch of input validation flaws going on in their web application. And again, this is a web application where you request certificates and are supposed to go through their rigorous domain validation process. Little more EV XSS, this time on thought. They're a pretty big name. So the question was, are these trusted root certificate authorities, or are they trusted by all the major web browsers? And the answer is yes. This is an interesting one. It doesn't look like much, but last summer when I was poking around trying to get my very first illegitimate SSL certificate, basically the website I was looking at failed open. It was kind of, I guess, to put it simply, the web application said, well, I don't really know who you are, so I'm gonna show you everybody else's data and you pick the data that you want. So I've done my best to mask somebody's tax ID number there, but that was a major certificate authority as well, somebody who should know better. Now, last summer, the certificate that I did end up getting was a certificate for login.live.com, which if anybody knows about Microsoft service offerings, hotmail, passport, the login.live.com is the main authentication portal. That's where you post your credentials to. What I didn't know at the time, though, I got this regular SSL cert, they actually used an EV SSL cert. So last summer I could have been doing this talk, but, well, who knew? So we see now that certificate authorities, they're not doing everything they need to be doing, but then still, why would somebody want to hack a certificate authority? Well, number one, they're just like any other e-commerce website. They're storing personal and business information. They've got credit card numbers, but personally for me, I'm not out to do this for any malicious purposes, but it's kind of funny that they have one purpose, and that's to make sure that they give certificates out to the people who are authorized to have them, and they just seem to be failing at that. So I say for the lulls, too, because it's pretty funny when you get one. But to come at it from a more technical point of view, we want to take advantage of the trusted private keys. The trusted private keys that the CAs hold are what can sign a certificate to make it trusted by all these common web browsers, be it IE or Firefox, as well as other things like code signing certificates or personal email certificates. A little bit about the certificate authorities security measures in the domain validation process. Some of the things they look at are domain registration records. Some of them actually have phone authentication validation processes, which I haven't really explored, but mostly they focus on this email to this predefined list of authorized email addresses and the use of secret tokens. So they send an email to the email address specified, and they send the secret. Now what these tokens look like actually varies from CA to CA. So the first one we see from Thought looks a lot like an MD5 hash. I've tried to guess what's in it. I haven't been able to. The second one is from GeoTrust, believe they're owned by Verisign. Below that is the Komodo authentication token, and then each CA has their own URL where this token or secret needs to be passed into, and that's where they say, well, we don't know what this token is, you can't do anything, or okay, we know that token. Do you want to approve this SSL certificate and let it get issued? So that's one of the keys there. If you can figure out how a certificate authority generates this secret, you can own that certificate authority and generate as many certs as you want. I haven't been able to do that yet. Maybe one of you can. One other thing I found is that some CAs actually have a blacklist, meaning that if you try to get a certificate for like, well, I tried to get one for verisign.com. And I got flagged, I got a little greedy there. So there are sites that are on these blacklists, and that's okay. I mean, it's better than nothing, right? That's good for verisign, good for Bank of America, good for PayPal, but what about, I don't know, dod.mil or dod.gov or whatever random host name it is, any one of us might be trying to secure. For example, sslvpn.yourcompany.com. Probably not gonna be on the blacklist. Now before we get into the real CA attacks, I just kinda wondered, I don't know, people leak stuff on the internet all the time. So yeah, you can Google for RSA private keys. I spent a whole day going through everyone in Google, and you know, it's kinda cool, it's funny. I only ended up getting one full key pair. You know, I found their private key like this, and then I just downloaded their ssl certificate, put it together, and it was for, I don't even remember the domain name. You know, if Bank of America is gonna fall victim to this, we got bigger problems to worry about. But still, kinda funny, kinda cool. This past winter though, you probably heard about the MD5 collision attack, where a number of researchers used 200 playstations and some crazy crypto attack to generate their own rogue certificate authority. This kinda trumps anything I'm gonna talk about, cause I'm talking about getting a cert here, a cert there. These guys were able to build their own certificate authority that was just trusted by every major web browser. And they did that by exploiting weaknesses in MD5 hashing algorithm, which has been known to be broken for a while. So they did this crazy crypto attack using their 200 playstations, but the type of crypto attack they did was called a chosen prefix, where they had to get something from a specific certificate authority with known data that they've provided. And the way they did that was through an automated script that basically got certificates out of this certificate authority through their web application. So what could have kinda stopped them dead in their tracks or drastically increased the complexity of their attack would have been a hardened web application. The two specific attributes that they needed to be able to predict in the certificate authority were the time of issuing, the exact time and seconds that the certificate was issued, and the serial number. And they were able to do that through this web app. If this web app just added a simple random time delay in the issuing process, I mean milliseconds, seconds, nothing much, would have drastically increased the complexity of this attack, similarly if they used non-predictable serial numbers that would have happened. So essentially here, yeah, we've got a broken crypto algorithm and this crazy crypto attack, but if the web application was designed with a defense in depth attitude, maybe this attack wouldn't have happened. Another certificate authority attack that happened last year, a user simply went to a reseller of the Komodo certificate authority, asked for a cert from Mozilla.com and got it. The answer, validation was turned off. Whoops. When I started looking at some Komodo resellers, what I found was that the reseller itself actually controls the whole authorization process. So while Komodo goes through the web trust audit and jumps through all these hoops and pays a lot of money to actually become trusted by a web browser, they sign up resellers and then just offload the whole process of validating certificate requests on them. So what you see here in this screenshot, I set up a domain to capture the email containing the authorization code and it actually came out of the CA resellers shared hosting environments SMTP server. So what that means is, hey, you own that shared hosting environment well, you can pretty much generate certificates signed by Komodo at your will. But why try and own the shared hosting environment when you can just sign up and be a Komodo reseller with a cash credit card? So that's on my list of things to do. Now, here's the attack that actually kind of spawned the title of this talk. There's another certificate authority called Startcom which I stumbled across. Essentially, they do it a little bit differently where they have a validation mechanism that you go through, you become validated for a domain and then you can request certificates for that domain. So here I am, I'm requesting to be validated for IntrepidistGroup.com, which is the company I work for. And then they say, okay, well, we're gonna send the verification email to one of these three email addresses, pick one. I picked one, but then I met in the middle of my browser session using a local client proxy like Paros and I changed it from whatever it was to my Gmail account. Then I checked my Gmail. And then I got the secret. And then I did it a couple more times, as you can see. And then I got greedy. So essentially, you could become validated for PayPal.com, you could become validated for Verisign.com, but then when you went through, hey, give me the certificate, I want it now, that's when you went through their blacklist and they happened to blacklistverisign.com. And within a couple of minutes, I had an email from the CEO saying, oh, it looks like you figured out how to bypass our validation mechanism. I was like, yeah, you know, I was writing up the disclosure, I didn't have a chance to send it yet. I really was. But Start.com was really cool. I mean, they fixed, this was December 23rd, two days before Christmas, they fixed it that night and I validated the fix. And I thought that was really cool. Another one, not as leet, but still very effective. This is how I got the login.live.com cert. It was through information leakage. Who exploits information leakage? Come on. So here's the aliases you could pick on their order form. There's like 10 of them, whatever. I couldn't register any of those at login.live.com. But they sent me an email, which contains some more. I registered SSL certs at live.com, got it, got the email, got the cert. And I'm out of time. But if anybody has any further questions, definitely come up and ping me. Reach out to me and I'll tell you all I know.