 I'm Len Sassman. I'm going to be talking about stupid authorities and their use with SSL. Following me is Dario Diaz, talking about the Digital Millennium Copyright Act. And after Dario is substitution, Stephen Sue, and I have his talk right here. It's IP spoofing and strong encryption in a servers-free internet. OK, so today I'd like to discuss a bit of technology that most of you are probably familiar with. You've at least encountered doing financial transactions on the internet, browsing secure websites. That's SSL. And if you've ever used SSL, you've relied on a certificate authority for part of the security afforded to you in the transaction. Now, one of the questions I'm going to focus on is what is a certificate authority, especially in relation to web browsing and SSL? And exactly what does a certificate authority do for you? Why do you need one? The purpose of a CA is to verify a set of facts about an individual or an organization. And then it presents them to the people that need them in a way that cannot be spoofed or faked. This is traditionally done through the use of X5 and 9 certificates. The CA goes through its verification process, which I'll talk about in a few moments, and takes this information once it's been verified, embeds it in a file that is then signed with the certificate authority's digital key. And then that's distributed out to the people that are going to be using it. This is this digital certificate, the signed file collection information is verifiable offline. You don't need to contact the CA whenever you want to verify it. You will typically encounter SSL certificates when browsing websites. Website certificates generally contain a URL, a company name, contact information, the most importantly, the copy of the web server's public key. That particular piece is really all that's necessary. The rest is pretty much irrelevant because the CA is really not providing you with anything except the verification, and they do a pretty lousy job at that. So the most important aspect of SSL is the encryption. The CA's don't provide encryption. They don't sell encryption. They don't make your website secure. That's all done with server and client software. Your browser has the ability to use SSL. It doesn't need a CA. And the web server is set up with software that's purchased or provided by the website administrators. All that a CA does is provide an assertion of identity. Most commercial CA's have historically weakened the security that you get when you're browsing websites because they charge significantly more for higher encryption. You can have a choice of 40-bit certificates and 128-bit certificates. There's no difference in cost to the CA. They're not doing anything except specifying what strength can be used. All that's handled on the web server and in the browser. So the CA obtains and verifies credentials of the entity applying for a certificate, constructs a certificate with the user provided information, signs it with their root key, and the actual process of encrypting the data exchanged between the web server and the web browser is entirely handled by software that the users and site administrators provide and maintain. If all you desire is encryption of the data you're transmitting through a web server or that your customers are sending to you, the CA isn't necessary. Why are they important then? Web certificates tie all of the necessary elements together. By verifying that a certificate originated at a respected CA and the certificate is still valid, one is able to tell that the public SSL key, the URL of the website, and the company all belong together. This helps prevent online fraud. For instance, if I were a con artist and I was interested in harvesting credit card numbers of unsuspecting web users, I could set up a quote unquote secure website with a URL similar to, for instance PayPal. Perhaps I could spell it P-A-Y-P-A-1.com. I could then intercept financial transaction information intended for the legitimate PayPal site. If I sent out, say spam with the link to my site or somebody mistyped the URL. If the user didn't realize that he typed the wrong URL or followed the focused link and didn't notice that this was not the actual PayPal site, he would fall victim to my scam. However, due to the use of digital certificates, the user would be alerted to this by warning messages in the browser saying the certificate wasn't generated by a trusted CA or similar error messages. CA's are far from a perfect solution, however. In order to successfully execute any of the attacks that CA's and CA issued certificates prevent, an attacker relies on a lot of luck and external variables. In order to masquerade as a legitimate site, as in my previous analogy, a con artist has to hope that the user will not notice obvious signs of foul play, such as the URL being wrong. And if the con artist operates for any length of time, he'll probably be caught when his victims become aware they've been fooled and reported. More successful methods of intercepting web form information would be either a man in the middle attack where communication is passed to an unauthorized computer between the client and server. However, an attacker would have to have a significant knowledge and level of control over a portion of the network that information is passing through for this to be successful. There are easier ways to compromise data. Passive sniffing, a rather easy attack, is prevented because of the SSL encryption being used. You can't set up a server to watch network traffic if it's being encrypted between the point of the client and the server. One major security weakness in the current quote unquote secure website system is the source of trusted root certificates for the CAs. These certificates, the root certificates are certificates that belong to the CAs themselves, contain the public key for the CA and are used by your browsers to verify that a server certificate is legitimate. You're presented with a server certificate, it verifies the signature against the public key root certificate. And if everything checks out, it passes you on to the secure site without new warnings. You'll notice the little cute lock in your browser, turn locked. If a certificate is signed by a root certificate that's not in the browser, you will be notified by a scary pop-up message saying something like there's a problem with the site security certificate, that's I believe internet explorers verbiage. If a certificate is signed by a root certificate residing in your browser, there's no warnings. And therefore the ultimate level of trust lies not with the CA, but with the browsers and the browser manufacturers. In the version of internet explorer that ships with Windows ME, there are 107 trusted root certificates in your browser. 107 certificates that can sign public server keys and not present you with any warning messages and assure you basically that those server sites, those server certificates are valid and safe to transmit information to. You can look at these yourselves by opening up internet explorer, going to the tools, internet options, clicking on the content tab from there, clicking certificates, and then clicking the trusted root tab. I'll say it again slower if anyone cares, but the point with that was it's not too easy to go in and look at this. They don't make it really obvious to find. It's fairly simple to add certificates to the certificate store, the trusted roots. If someone added a bogus root certificate to the browser's list of trusted roots and was able to get you to use that browser, he could then issue quote unquote valid website certificates as far as the browser's concerned and you would trust them implicitly. This is basically a simple easy method of creating a Trojan horse version of IE or an escape without altering the program at all. So you have to be certain that you're obtaining your browsers from a trusted source and they haven't been altered in any way. Or for instance, if one of those legitimate 107 roots were not protected, the same results could be obtained. What do you know about, for instance, the security of GTE cyber trusts certificate? I'm not trying to single out a particular company here but that root certificate has changed hands. I believe Baltimore owns it now. What assurance do we have that it hasn't been compromised in the transition? It would be held accountable. What's to say that even certificates that have never left the company that they were originally issued in haven't been compromised? Another major problem with the existing CA structure is the lack of a working certificate revocation system. As I previously mentioned, one of the benefits of using digital certificates is the ability to verify their authenticity offline. However, in order to obtain information to be certain that the certificate is not revoked, one must contact the certificate authority for this information. A certificate would be revoked if it was legitimately issued, but later compromised or suspected of being compromised. It is because of this lack of a good revocation mechanism that short expiration times on certificates are encouraged. Part of the information embedded in the fields in a digital certificate is the validity time. There's a start date and an end date for when the certificate is valid. It shouldn't be used before the start date and it shouldn't be trusted after the end date. This applies to CA routes as well as service certificates. Now it's not a huge deal if a service certificate gets compromised or expires, you reissue a new one. But with root certificates, the issue is much more important because there is a lot of trust put in the root certificates and the compromise of a root certificate affects a large number of service certificates. If the compromise was of a leading CA like Verisign, the results would be devastating. Several years ago, certificate authority thought lost a good number of customers when its root certificate expired. Explorations are healthy. The longer a key is in existence, the greater the chances that it will be compromised. Unfortunately, thoughts customers saw this as a hindrance to their customers, for it was, and a lot of them moved off to Verisign. When you try to go to a website that has a legitimate certificate issued by a root that's been expired, scary browser messages pop again. Users don't like that. Verisign was quick to capitalize on thoughts mistake. Verisign, in turn, had the same problem at the end of 1999 when their root certificates expired. The fact that it was at the end of 1999, however, led a lot of people to believe it was a Y2K problem and they were more forgiving. Or Verisign as a better marketing spin machine. Remember, the general public expected their refrigerators to stop working as soon as the year 2000 came around. So it wasn't hard to get them to forgive that. Thoughts expiration time was perhaps a little too short. But now, if you look at your browser and the root certificates, most of them expire between 2015 and 2020. Thoughts expire in 2020. Some of Verisign's expire in 2028. Do you plan to be using Internet Explorer 5.5 in the year 2028? These certificates have such a long lifetime that they might as well have no expiration at all. The trust process involving CAs is riddled with potential pitfalls. One assumption we all make is that the CA will actually do its job. It's a reasonable assumption. We expect them to verify that the entity requesting the certificate is actually authorized to make that request. Recently, Microsoft got some bad press when two digital certificates were issued in its name to an imposter. I dislike Microsoft as much as the next guy, but in this case, I had to feel bad for them. The blame here lies with Verisign, who fell victim to a social engineering attack. They issue hundreds of thousands of certificates. It's bound to have happened. But given the fact that Verisign can make mistakes, do you really want to rely on it blindly for assurance that sites you're visiting are legitimate? Or is the threat itself so minimal that Verisign or other CAs are nearly irrelevant? Users should be accustomed to examining website certificates before transmitting their sensitive data. The information they are submitting is sufficiently sensitive, then this inconvenience is warranted. If not, then the CA isn't needed at all, but isn't a CA necessary for SSL. The CAs would like you to believe that. But as I previously stated, the encryption is handled by the software running on the web server and the software that comes built into your browser. So, how does a website admin get an SSL certificate, if not through a CA? Most SSL software allows the generation of self-signed X599 certificates. In this case, all the certificate information is signed by the key of the web server, the key that's actually embedded in the certificate. There is no chain, no root certificate. You are trusting that the certificate presented to you belongs to the website owner. This will set off alarms in the client browser. Unfortunately, many people would rather use no encryption at all and thus receive no warning about invalid site certificates than trust a self-signed certificate. This is foolish. When a browser warns you about a quote unquote untrusted certificate, it isn't saying that the certificate is one you should not trust. It is asking you if you wish to trust the certificate and it asks you this on a case-by-case basis. Users should become accustomed to approving individual self-signed certificates. The dangers of submitting information in the clear without any encryption are rather high, for it takes little effort to set up a passive network sniffer if you have access to part of the network that the information is traveling over. Passive attacks are relatively low risk to the attacker and they are generally undetectable. Passive attacks are the main threat to a compromise of privacy while communication is occurring. Though it should be noted that most e-commerce server compromises that result in loss of customer data, credit card information, et cetera, are attacks against the databases that store this information for the payout as much greater. The attacker attains a large number of credit cards at once from the customer database server rather than stealing them individually over the wire. Most of the attacks against data that is being transferred will be attacks against data sent in the clear. They are passive attacks and most will be opportunistic. If encryption is being used, the attackers will not attempt to defeat it. Instead, they'll seek out a different, easier target. SSL is very good at preventing such attacks. Does a poor job of protecting against the remaining small minority of threats. But these attacks are difficult to execute. The attacker is determined enough to attempt a more sophisticated attack. The use of a CA will only provide a speed bump, not a barrier. So, SSL should be used for all user submissions to websites where the information being sent is sensitive, regardless of the origin or issuer of the site certificate. Unless the site is clearly bogus. If the website administrator can't afford the CA's fees, he or she should use self-signed certificates. Users should become accustomed to approving certificates on an individual basis and shouldn't allow the browser warning messages to scare them. One of the difficulties with that is that many administrators aren't aware of how to generate self-signed certificates. They like the ease and convenience of the certificate ordering process that commercial CA's provide. And they don't wish to learn how to make their own certificates or they don't have their own time. The FreeSERD project is an attempt at a non-profit certificate authority. Our main goal is to provide certificates to sites whose administrators wish to use SSL that desire is not an overwhelming need. They don't have the time or ability to learn how to generate their own certificates and don't have the incentive or the budget to purchase a costly SSL certificate from a commercial vendor. Our main target audience is small businesses, individuals, and non-profit organizations, though anyone is welcome to request a certificate. We should be online within the next month and a half. Initially, FreeSERD will be offering website SSL certificates and providing a minimal automated email ping verification of the site administrator. FreeSERD routes will be available for download from the FreeSERD.org website. Users can import them into their browsers and have the option to trust them or to review certificates on a case-by-case basis. FreeSERD routes will not be automatically trusted by your browser. This is how all browser route certificates should be, however. The user should have to go into the browser and specify which routes he's willing to blindly trust. There shouldn't be any routes in there that are, by default, trusted. The desired outcome of this project, if it is successful, will be to make web users accustomed to approving or denying individual site certificates. They're going to see these error messages a lot if FreeSERD's use is widespread. They're no longer going to find these warning messages terrifying and they're not going to stop their browsing because of it. Large majority of users will probably, and already probably do, just click the okay button and go through, but ones that are concerned by this should go in and examine every certificate that they encounter for the first time and choose to trust it or not. We wish to increase the number of SSL secured websites on the internet. FreeSERD is not competition for Verisign. Instead, we're competing against the unsecured web. I've spent a little bit of time today criticizing commercial CAs. I'd like to state that most of my complaints are with regard to the use of CAs for web server certificates. Other applications, such as client browser certificates, access controls, attribute certs, and so on, could definitely warrant the use of a trusted certificate authority. Initially, FreeSERD would not be doing anything in that area. We don't have the ability to do the level of verification necessary. For those of you who are interested, FreeSERD is looking for volunteers. If you have experience in project management, website development, shell scripting, feel free to email me at rabbi at freesert.org for information on how you can help. I could continue talking now about the technology behind FreeSERD itself, about the SSL process, or about CA procedures, but I don't have time to do all three, so I'd like to turn it over to questions and see what the audience wants to hear. Does anyone have any questions for me? Correct. It's a combination of public key and symmetric key. Right, it works both ways, though. When you're submitting to the web server, you're encrypting to the web server's public key. That's, it would be a random key that's generated for your browser. You can also request client certificates. I don't really want to go into that too much here because that's not in the scope of FreeSERD, but the same process that happens for the web server you can do for your client server and use your client certificate in lieu of a password for some sites. Generally, no, there is, right, the information being sent is signed as well. So if you're submitting the information, you have, okay, so the scenario here is you have a web server that's got a legitimate certificate and you've got your client there and you do a key exchange and you set up, encrypted to the public keys is a key for symmetric key. Symmetric cryptography is far faster than public key, so the actual data that's transmitted is all symmetric key. One thing that those keys, they set up the shared secret and then information is encrypted using a stream cipher or a symmetric cipher and that information is transmitted between the client and the server. I believe it's binary. It's, it possibly could be asking your arm but I'm not 100% certain on that, but you can't, you're not gonna be able to go in unless there's a flaw in the encryption algorithms that you're using and alter that. Yes, the question is, CRLs, is it a protocol shortfall in SSL or is it that most browsers haven't implemented CRL checking? It's pretty much both and it's largely a lack of a comprehensive collection of road certificates and a decent mechanism of pushing them out to the browsers. There are some protocols, OCSP, that attempt to fix this, but they are not perfect and they are not entirely reliable. FreeSERT will have certificate revocation lists but there's the same problems that exist everywhere. We won't be solving any of these certificate revocation issues. If you're concerned, you can go and get the certificate revocation list. Most users don't do that. That's the problem. Here. I can't send, I was wondering if you had any comments on the user verifying. Oh boy. Now I'm gonna pick on thought again. So, what Russell said here was he's been looking at verifying fingerprints of service certificates and CA route certificates. The fingerprint is a hash of the certificate, basically and a hash is a mathematical calculation that gives you a unique or unforgible smaller string of numbers that correlates to the data you pass through that procedure. The point of a secure hash is that you can't find a desired outcome of numbers by specifying the information you're putting in. It's a one-way function. So, these are used to generate fingerprints on keys which allow you to very easily confirm that you have a valid key. We could conceivably read off all the numbers in the key but that would take a long time. The way to actually check and make sure that you've got a legitimate certificate regardless of the CA is to confirm with the person who actually is authorized to have the certificate what the fingerprint for that certificate is. Now I don't suppose you can go to eBay and click a button that says here's our web server certificate fingerprint and I wouldn't really expect the individual sites to be doing this but the CA's who are in the business of trust should have a mechanism to verify their root certificates. As I said, a root certificate compromises all the certificates issued by that root not just the one server certificate. A friend of mine called up thought a few years ago. He made a long distance call to South Africa and he said he wanted to verify their fingerprint of their root keys. They didn't know what a fingerprint was. I think that's all I have to say on that. He explained, they call it thumbprint in some browsers, they call it message diagist, there's, they finally got the idea eventually and then they said we're not authorized to give that information out. So, but you shouldn't have to make a call to the CA. There should be sections of their website that have this information. Now of course if their website is compromised that information isn't trustworthy but there should be mechanisms for users to verify this. That's something that we'll definitely be doing and in fact I've also been thinking about keeping a list of the fingerprints and fingerprints tying to URLs of certificates we issue. So if you wanted to go to our website and verify a fingerprint, you could pull up a list of certificates we've issued. It'll show it's, whether it's expired or revoked or not, the URL and the certificate. Yes. No, you can't, the reason fingerprints are used is you can't work backwards. You can't take a fingerprint and say okay, now I want to generate a key that matches up with this. If you can do that, then that's a cryptographic attack against the message diagist algorithm and there's severe problems with it. Not secure hashes. Well actually what I was just talking about was the fingerprint of the certificate itself, not the actual transmission. You have a certificate, you pass it through the hash, you get the fingerprint. You can't work with a fingerprint and move backwards and get a certificate that matches up with it. The only way to do that is a brute force attack where you basically generate hundreds and thousands of certificates and look for one that matches and that will take a long time. Yes, right, they are not cryptographic problems. Right, I'm not addressing cryptographic problems here at all. It is largely an education issue and that's what FreeCert really is, it's an education project. We are going to be throwing these untrusted site certificates out there and it's going to make users question what exactly is happening here. We will have explanations on our website and hopefully users will become more educated as they encounter more of these certificates. Sure, I suspect most of the client sites will want to put a small message saying for information about our security, go here and come to our site, but yes, that would be good. You trust something, yes. And you have to, it's up to the user to make the, my whole point here is it's up to the user to make that decision. It should not be up to a browser which is, browsers are distributed from non-trusted sources. You don't download a PGP signature with the browser and verify that the browser hasn't been tampered with. These decisions are being made for the users without their understanding of what exactly is being decided for them. So yes, you have to place your trust in something and there is not total security here unless you go and talk to the IT administrator of if a free start is one of the, yes, the hundred can't play as well as the fifteen. So you're asking, you're asking why I wouldn't go and get free certs, routes put into the browser and just become another blindly trusted CA. That's the entire issue I'm trying to fight against here. We don't need another blindly trusted CA. All I'd be doing was providing free certificates out. And we're really not doing enough identity verification. Which you aren't that. The way we're constructing things we're basically sending out an email paying similar to a lot of mailing the software does to the technical contact of the site. And if it comes back valid, we'll issue this certificate. That's the initial first untrusted level we'll be scaling up as we have more staff. But what we really wanna do is make users aware of what's happening here. Even if they can't make the intelligent decision that this is trusted or not. They at least know that there's that risk. A lot of them right now aren't aware that there is a risk that they might be sending stuff to the wrong site. But again, the probability of an attack being executed against the site's certificate and being spoofed is very slim. What really is important is the encryption. The chances that you're gonna be encrypting to the wrong website are minimal. So I want to encourage these certificates on places where the certificates aren't already being used. Let me get one in the back here. There's somebody waving their hand. No, okay. We have a Chris Ricks. Ricks. Okay, any other questions? Yeah, we're aiming to make people aware of the fact that they're deciding to trust something that is not 100% trustable. You can call me up and confirm fingerprints. But yeah, what you do is you, with the trust model here, you keep narrowing and narrowing the probability of attack, but you never get that probability down to zero. There is no such thing as total security. Yes. And a probability of authenticity, but not an assurance. You want to accept the certificate. What would you recommend that people do verify a certificate? So they first have the way, the value of the information they're submitting. Use your American Express card on the internet. You're not responsible for fraud. So if your number's stolen when you're submitting it, there's no out-of-pocket expense for the user. And most other credit cards, it's a $50, $50 you're responsible for the first $50 and then the rest is eaten by the credit card company. So if they decide that, okay, the stuff I'm submitting here is super secret and I need to be sure that the site I'm submitting to is the correct site, what I would do is the best way would be to locate the number for the website, just send it to the company and talk to someone in their IT department and find out the fingerprint. He's saying that the information he's submitting, it can absolutely not go to the wrong people. Right. So it would determine how risky this transaction is to measure that against... Well, that is a decision that has to be made by the user. I mean, I can't tell you what your metric is. I would, you can do an examination of the information that's embedded in the certificate and see if it, you know, sanity check it. If this is a company registered in Russia and it's supposed to be a U.S. e-commerce company, that's a red flag. It's all basically whether or not this looks legitimate and it's very subjective. We are using, we're using OpenSSL and we have some modifications to it. We have, for our key management devices, we're using an end site for secure key management hardware device and this is all in Sun hardware. In the back there. This is all being done by a series of volunteers right now who are donating their time, their bandwidth and their hardware. We have, we're working with the Shmoo Group and the Crypto Rights Foundation as well. Yes. Yeah, right now it's all volunteer donations and the free certificates are the ones that are the low level email ping verification. If we end up having the ability and resources to start doing more in-depth verifications, we will probably be charging a minimal fee and that will go back into funding our resources. FreeCert.org. Let me see if there's any other questions about services certificates. I can talk briefly about personal certificates but that doesn't, that's really not what I've been addressing today but I will talk about that if there's interest. Are there any other? Yes. So you're talking about an internal, for an internal PKI you don't need a CA at all. You become your own CA because I assume you're talking about your quote-unquote customers are your employees. Right, you don't need an external CA. The external CA is basically for use on the internet at large. If you are setting up an internal PKI, you generate your own route with the software you have, the encryption software. There are some open source software solutions out there that are difficult to set up and configure and there's some low-cost commercial PKI systems and some more expensive PKI systems. You generate your own route and you push that out to the browsers of your employees and then that's trusted. And you can extend that off, it doesn't have to be just website browsing, you can use that for client certificates, you can use that for access controls for to your VPN and your IPsec applications, et cetera. Our website is very minimal right now. We're looking for more volunteers. We intend to have a whole education system where we'll provide information and assistance to companies that wanna go about setting up something like that. There was somebody in the back there who had a question. True, there are a lot of people that would just say yes even with any warnings whatsoever. I'm not sure exactly what your question is. That's done by the browser. If it's not a science certificate from a trusted route, it's going to warn you that it's not a trusted. It's gonna be exactly, it'll pop up in what OS? That, to my knowledge, isn't correct. I don't know about XP, but Windows 2000 and ME still warn you if you're not using a trusted, if it doesn't originate from a trusted route. Anyone else? You still get a warning if it's not trusted. Right, I think we have time for a few more questions. Anyone? Okay, if anyone wants to see me afterwards to talk about any of this in more detail, they can feel free to find me. Or you can email me, rabbiatfreecert.org. Yeah. So next up we have Dario Diaz.