Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
Posted
by
michael
from the snake-oil-enterprises dept.
lisam writes "Rob Flickenger shows how to become your own Certificate Authority, and sign your own, or others', SSL certificates in this onlamp.com article. (He also manages to mention fnords and deny responsiblity for the Microsoft Corporation cert snafu.)"
This discussion has been archived.
No new comments can be posted.
It's important the people understand how to do this, but what is missing is some way to understand whether or not to trust a CA. Until your grandma can trivially decide to trust rw2's CAnonical Enterprises, Inc. signing by anyone but the handful of big boys is the most reasonable thing to do.
I've thought the only way for a new entity to establish a trust relationship is to tie into some existing entity with a surety bond.
If rw2 CAnonical Enterprises, Inc. could convince me that some chunk of money backed up any and all claims of their identity, then I'd be willing to transact business using them.
But I don't see how to do this unless the existing entity is a bank. From what I understand, becoming a bank is no trivial task.
Reasonable in that it is easiest, yes.
Reasonable that it is the most financially viable option, not necessarily. Not if you need a *lot* of certificates, like I do.
Reasonable, to pay VeriSign's extortion? No. No on principle.
There is no loss of encryption in not using an "big boy" (which I mean to be an established CA). My ssl is just as secure, in terms of encryption. My only disadvantage is that my visitors have to trust that I am me; I don't have to have VeriSign vouch for me. Arguably, since my CA private cert is in a safe, I am *more* secure, cause I don't have to worry about Verisign F-ing up like they did with MS.
My only disadvantage is that my visitors have to trust that I am me
Kind of a big disadvantage one might think...
Calling it extortion is innacurate, they have trust and that's a big thing. If it were easy to duplicate someone would have done so and competition would drive prices down.
Arguably, since my CA private cert is in a safe, I am *more* secure
You can argue that, but it's a loser. People are far, far more lax about security than verisign is.
Kind of a big disadvantage, one might thing...
Heh. Yup. No doubt about that. But, I think, easily dealt with in my specific circumstances (or I obviously wouldn't go that route)
Calling it extortion is inaccurate, they have trust and that's a big thing....
It is not trust that they have. It is the fact that they are installed in browsers out of the box. I don't trust VeriSign; neither does my grandmother; she's never heard of them. But Microsoft (et al.) have decided for her that VeriSign, Thawte, etc are trustworthy.
You can argue that, but it's a loser. People are far, far more lax about security than verisign is.
What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy. Point A: people tend to get stupider in large numbers. Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy.
Besides; we are not talking about "people" in general here... I gave myself as a specific example; you know nothing of my security practices, how can you even begin to back up a statement that general?
It is not trust that they have. It is the fact that they are installed in browsers out of the box.
They have the trust of the browser vendors. You say this yourself. This is no small bit of trust.
What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy.
That's right. And, regardless of whether you accept a Randian world view or not, each of those people are looking out for their own best interest. That means that security on the systems is likely to have been designed well, the audits to find holes are likely to have been done properly, the customer service has provided feedback to make it more likely that their product is used properly. On and on and on.
Verisign has done a mostly excellent job of providing a robust service.
Point A: people tend to get stupider in large numbers.
This is simply false. People without common goals tend to do stupid things while sniping at each other. But to say that, for example, GE is doomed because people get stupider in large number is, well, stupid. It's not even a recent phenomena for heavens sake, the great wall of china was built by a large number of people, so were the pyramids. Those two are examples of engineering that is far from stupid.
Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy
I disagree with this. Showing me one example (the microsoft one) doesn't show that they are 'generally' untrustworthy. And more to the point, it certainly doesn't come close to the level of proof needed to show me that they are less trustworthy than having 100 million net users manage their own private keys.
Besides; we are not talking about "people" in general here... I gave myself as a specific example; you know nothing of my security practices, how can you even begin to back up a statement that general?
I didn't say *you* couldn't, though I doubt you can unless you work in security. I work on the fringes of security everyday and am glad that kerberos, and the professional security types at my lab, are managing my keys instead of me.
No one can really answer that, because there isn't any way for Grandma to know whether or not she can trust a CA. Even if it's the big guys or if it comes with her browser. I mean, from Grandma's point of view, who the hell is Verisign and what did they ever do to merit trust? At best they're just some faceless corporation she's never heard of or dealt with. A cracker CA named "Integro-Trust Digital Signature National Registry (Fidelity Verified)" would have an even better-looking name than "Verisign."
I don't think you can have real trust without users understanding how things work. Grandma is screwed.
Let's face it, Grandma doesn't know squat about trust, in this context. She probably doesn't even know that the concept is important. We're doing well to make sure that Grandma looks for the little lock in the corner of the browser whenever she enters private information.
As for trust, Grandma trusts whoever set up the computer for her, and it effectively means that she trusts Microsoft and/or Netscape (or maybe Opera) for putting those little locks on her browser.
Are there any legal issues to violating the chain of trust implied by that little lock in the corner? Obviously if money is stolen, there are laws in place. But what about the trust, itself?
First, trust isn't vital in all circumstances. You *need* to trust the cert if you're doing something like buying stuff online. That's logical, you need to be sure that the site is owned by the company you expect, and not a script kiddie.
For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.
Sure. The point of encryption is to secure a connection. If you can't trust the cert, then you can't trust the encryption. Ergo, you may as well be using plaintext.
For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.
Huh? I don't follow this. Are you saying that because they copied your mail the security doesn't matter? What of a man in the middle attack?
All a trusted cert certifies is the identity of the owner. That's all. You want it to buy stuff online, because of course you want to have some guarantee of that you're giving your credit card number to the right person. All a certificate signed by Verisign gives you is their confirmation: "This guy paid us for the certificate, and presented us documentation that identified him as John Doe"
For other things, trusting a cert doesn't matter so much. The connection is encrypted regardless of trust, so you can be sure that there's nobody in the middle sniffing the data. That's actually as good as it gets. Verisign will give a cert to anybody with money and a proof of their identity. It won't save you from an evil sysadmin who suddenly decides to make your mail public, for example.
I use a SSL connection to a Jabber server that uses a self-signed cert. What does that give me? All data between my server and me is encrypted. That means that my ISP can't know what I say to people, or what people say to me. Trust isn't really an issue here. Pretty much everybody else uses an unencrypted connection to ther IM server.
Ok, I see what you're saying. But you're talking about something different.
Trusting the cert does matter. Because it is an identification of a policy. You acknowledge as much when you say that Verisign was presented with "documentation that identified him as John Doe".
I agree that this matters for commerce. But I disagree with your comment that it doesn't matter for much else.
You, for example, use a self-signed cert to talk with your SSL based Jabber server. Why do you do this? Because you trust the cert. You trust that it was signed by someone that won't let your Jabber server be spoofed by a man in the middle. In this case, that person is you.
But do you think that anyone should trust that unknown CA? Should I, when presented with a CA that I don't know the policy of simply accept the cert? No, of course not, to do so would allow people to read my IM stream. Do I care about this less than my back account, sure, but not a ton less. My credit cards are insured against fraud, so what do I care if someone steals them. Heck, that happened to me just last year.
I agree that your self-signed cert protects you against people snooping your connection. I just don't agree that trust isn't an issue. It is an issue, and you've chosen to trust yourself as a CA.
Hmm, I think I didn't explain very well. The self-signed cert on the Jabber server wasn't made by me. It was made by some random person somewhere. To explain why in this case a Verisign cert doesn't matter much, let's compare:
Unencrypted connection: Data transferred as clear text. It can be snooped easily.
Encrypted with self-signed cert: Data encrypted with SSL, but no signature from Verisign.
Encrypted with signed cert: Data encrypted with SSL, with a Verisign signature.
What's the difference between those two? That Verisign claims to know who that guy is. Does it do me any good? Not much, probably. I could trust Verisign to check that the certificate includes the real name and location of the server's owner, so that I could say, try to sue him if he decides to log all my messages and put them on his site. Or maybe they could revoke his cert, which they most certainly won't do. After all, how do I prove that the embarrassing log published on foo.com is mine? There's no sure way for me to prove it.
This probably won't do me much good, however. Suing somebody in another country, whose server I used without any kind of agreement (even clickthrough one) could be complicated. And I could do that without Verisign anyway, I'd just have to hope that the whois info for the domain name lists the right name and address.
I think you're a bit confused about what a 'signed by Verisign' cert means. It means that Versign says it knows the cert's owner. It's the same thing as if your friend Fred comes to your friend Joe with a piece of paper signed by you, to prove that he's somebody you trust. This has absolutely nothing to do with the effectiveness of the encryption itself.
Trusting a random CA has the same effect as Fred deciding to trust Joe when he gives him a letter signed by some random person he never heard about. But again, this doesn't have any influence on Fred's and Joe's ability to have a private talk.
For people to be able to read your IM stream, one of these things should happen: The encryption is broken, the encryption is brute forced, the server's private key is compromised. That last option is the most likely, and is archieved by breaking into the server, or the owner giving his private key to somebody else. Verisign's signature doesn't matter at all for this.
For people to be able to read your IM stream, one of these things should happen: The encryption is broken, the encryption is brute forced, the server's private key is compromised. That last option is the most likely, and is archieved by breaking into the server, or the owner giving his private key to somebody else. Verisign's signature doesn't matter at all for this.
This isn't true. There is a third option, I've mentioned it a few times. A man in the middle attack. This is why the trustworthiness of the CA is important.
If you can't trust the CA then I can get a cert signed (or sign one myself with my CA) and position myself between you and your jabber server. When you try to connect to the jabber server you instead connect to me, I see the text in plaintext because the channel was encrypted using the cert that I provided you. I then turn around and contact the real jabber server and forward the traffic. Thus, to you it looks like you've connected directly, but I've managed to read the entire stream. This occured because the CA wasn't trustworthy and you trusted it anyway.
You keep focusing on the stream after it's been established. I agree, any cert, signed or not by any CA is sufficient to encrypt a channel. It is not, however, enough to *secure* a channel. For that you need to better identify the holder, which is were trusting the CA comes in.
It doesn't completely exclude a man in the middle attack. Here's an example: seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe.net or.org? It's quite possible to catch at least a few people this way. For an example of this, see whitehouse.org. Verisign would sign their cert just fine.
A second option is that you break into my jabber server, take the cert, and use that for your attack. This should work as long as the Common Name matches your domain name. Then, the program might be brain damaged and not check that at all.
A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server. If you get in the middle, the cert will be different, signed or not, and I will be warned. This is how SSH works, for example, if I connect to a system whose key changed I will get warned. Knowing the fingerprint of the cert can be good enough as well to determine that you're connecting to the right server.
While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine, and a self-signed cert isn't completely insecure either.
It doesn't completely exclude a man in the middle attack. Here's an example: seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe.net or.org? It's quite possible to catch at least a few people this way. For an example of this, see whitehouse.org. Verisign would sign their cert just fine.
While this is all true, it doesn't for a moment have anything to do with the issue at hand, whether or not you the CA signing a cert must be trusted. I never asserted that the signing CA was the *only* thing that must be trusted. It is, however, part of the chain.
In your example, the user must also be trusted to connect to who they want to. seerver.com was correctly identified and the user errored in his typing. The user can still trust that seerver.com is who versign says it is.
A second option is that you break into my jabber server, take the cert, and use that for your attack.
Yes, this is a point where PKI is weaker than some other approaches. It too, however, is orthogonal to whether or not the CA must be trusted.
A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server.
Strictly speaking I claim that the CA must be trusted. I've also argued that there should be a system by which people can more easily gage whether or not to trust a CA. I've not said that a signed cert was, a priori, untrustable. In fact, as in one of you examples I think, a self-signed cert *can* be better because you know that no one spoofed verisign. If they spoof you, however, then the issue remains the same. The CA must be trusted.
While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine
Agreed. It is, as I say above, an essential building block. Without faith in the CA the entire foundation crumbles.
The information that the article mentions above, has been readily available on line in various howto's. Just follow the instructions that come with OPEN SSL or MOD_SSL.
With all due respect. There are some things that ought to be somewhat complex. When one deals with network security one might want to make sure that he/she actually knows what their doing.
I find it hard to believe that the book 'Sappers for Dummies' would appear on the shelves any time soon.
Pretty disappointing. Anyone at/. that is interested in CAs and such should already be aware that OpenSSL has all the functions for manipulating the various file formats involved if you have the time to grok the command line interface to all of this.
I can give you more help right here and clear up some stuff they glossed over. First, a certificate is not a public key, but it includes the public key, and it is signed by the private key of the Certificate Authority (CA). In the example, a 'root' or self-signed certificate is created. The private key is typically password protected when it is stored (you can see it prompting for that password in the script).
He doesn't show you what you have to do to create the '.csr' file that is used to create the actual site certificate, but this is what is called the Certificate Request. Also, the '.key' file should be created in a separate step. The process is that when someone wants a certificate, they generate a request on their computer that includes all the 'name' information (as displayed in article) and the public key. The private key is generated at the same time, but it should never leave the site generating the request, and additional steps should be taken to protect it from being exposed. The article implies that the key pair is generated by the command given, but I don't think it is (a separate step is needed to create the.csr file, and it should be created then).
A few more notes: your new '.crt' (the certificate) file will show up in 'newcerts' (if not, then 'certs'), the 'serial' file is the serial number of the next (or last) cert issued, and the 'crl' subdir is for the "Certificate Revocation List" all CAs should have one, and it should list all the certificates issued by this authority that have been revoked (by serial number, I think). AFAIK, this is the biggest hole in the process. To correctly verify the validity of a cert, you should always check the cert's serial number against the CRL, but where to you get the CRL? There must be a standard way to get the current CRL from a CA, but does a browser or other client have any function to get it before validating a certificate? Nothing I've seen indicates that clients do this so I doubt whether revocation is ever effective in a practical sense.
Now, what would be really cool is if someone wrapped the functions to create a certificate request with a few web pages and provided a howto describing how to set this up and really run your own CA. If I was doing it, I would keep the CAs private key on external media (a floppy or CD/R), and only put it in the system when I need it to sign certs and CRLs. Isolating the system you use for this is better, but you do still have to get the requests in and the certs or CRLs out.
One final comment. It is just about impossible to actually protect the private key for a typical web server. Or at least protect it from root exploits. This is because you have to either not use a password so that your web server can restart without a password, or have some script that provides the password on startup of the web server. The only other choice is to have someone actually type it whenever a server needs to be restarted, and I don't have to point out here what a pain this would be for a big server farm.
While I frequently find valuable information in Oreilly's articles, such as this one,
this one is nothing but fluff; purely a plug for the author's book.
The exact info is available in the docs that come with OpenSSL, as well as in the OpenSSL animal book.
Feh, sorry this was so lame, I couldn't think of anything really funny. I just couldn't resist after seeing the example names, locations, etc. he used.
This is important, but... (Score:5, Insightful)
Re:This is important, but... (Score:3, Interesting)
I've thought the only way for a new entity to establish a trust relationship is to tie into some existing entity with a surety bond.
If rw2 CAnonical Enterprises, Inc. could convince me that some chunk of money backed up any and all claims of their identity, then I'd be willing to transact business using them.
But I don't see how to do this unless the existing entity is a bank. From what I understand, becoming a bank is no trivial task.
Re:This is important, but... (Score:3, Funny)
Well, you could always become a bank without becoming a bank... <cough>paypal</cough>
Re:This is important, but... (Score:2, Informative)
Re:This is important, but... (Score:3, Insightful)
Kind of a big disadvantage one might think...
Calling it extortion is innacurate, they have trust and that's a big thing. If it were easy to duplicate someone would have done so and competition would drive prices down.
Arguably, since my CA private cert is in a safe, I am *more* secure
You can argue that, but it's a loser. People are far, far more lax about security than verisign is.
Re:This is important, but... (Score:2)
Heh. Yup. No doubt about that. But, I think, easily dealt with in my specific circumstances (or I obviously wouldn't go that route)
Calling it extortion is inaccurate, they have trust and that's a big thing.
It is not trust that they have. It is the fact that they are installed in browsers out of the box. I don't trust VeriSign; neither does my grandmother; she's never heard of them. But Microsoft (et al.) have decided for her that VeriSign, Thawte, etc are trustworthy.
You can argue that, but it's a loser. People are far, far more lax about security than verisign is.
What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy. Point A: people tend to get stupider in large numbers. Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy.
Besides; we are not talking about "people" in general here
Re:This is important, but... (Score:2)
They have the trust of the browser vendors. You say this yourself. This is no small bit of trust.
What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy.
That's right. And, regardless of whether you accept a Randian world view or not, each of those people are looking out for their own best interest. That means that security on the systems is likely to have been designed well, the audits to find holes are likely to have been done properly, the customer service has provided feedback to make it more likely that their product is used properly. On and on and on.
Verisign has done a mostly excellent job of providing a robust service.
Point A: people tend to get stupider in large numbers.
This is simply false. People without common goals tend to do stupid things while sniping at each other. But to say that, for example, GE is doomed because people get stupider in large number is, well, stupid. It's not even a recent phenomena for heavens sake, the great wall of china was built by a large number of people, so were the pyramids. Those two are examples of engineering that is far from stupid.
Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy
I disagree with this. Showing me one example (the microsoft one) doesn't show that they are 'generally' untrustworthy. And more to the point, it certainly doesn't come close to the level of proof needed to show me that they are less trustworthy than having 100 million net users manage their own private keys.
Besides; we are not talking about "people" in general here
I didn't say *you* couldn't, though I doubt you can unless you work in security. I work on the fringes of security everyday and am glad that kerberos, and the professional security types at my lab, are managing my keys instead of me.
Re:This is important, but... (Score:5, Insightful)
I don't think you can have real trust without users understanding how things work. Grandma is screwed.
Who can you trust? (Score:1)
As for trust, Grandma trusts whoever set up the computer for her, and it effectively means that she trusts Microsoft and/or Netscape (or maybe Opera) for putting those little locks on her browser.
Are there any legal issues to violating the chain of trust implied by that little lock in the corner? Obviously if money is stolen, there are laws in place. But what about the trust, itself?
Re:This is important, but... (Score:2)
Dude, unless you *trust* the cert your 'encryption' is worthless.
Re:This is important, but... (Score:1)
First, trust isn't vital in all circumstances. You *need* to trust the cert if you're doing something like buying stuff online. That's logical, you need to be sure that the site is owned by the company you expect, and not a script kiddie.
For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.
Re:This is important, but... (Score:2)
Sure. The point of encryption is to secure a connection. If you can't trust the cert, then you can't trust the encryption. Ergo, you may as well be using plaintext.
For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.
Huh? I don't follow this. Are you saying that because they copied your mail the security doesn't matter? What of a man in the middle attack?
Re:This is important, but... (Score:1)
All a trusted cert certifies is the identity of the owner. That's all. You want it to buy stuff online, because of course you want to have some guarantee of that you're giving your credit card number to the right person. All a certificate signed by Verisign gives you is their confirmation: "This guy paid us for the certificate, and presented us documentation that identified him as John Doe"
For other things, trusting a cert doesn't matter so much. The connection is encrypted regardless of trust, so you can be sure that there's nobody in the middle sniffing the data. That's actually as good as it gets. Verisign will give a cert to anybody with money and a proof of their identity. It won't save you from an evil sysadmin who suddenly decides to make your mail public, for example.
I use a SSL connection to a Jabber server that uses a self-signed cert. What does that give me? All data between my server and me is encrypted. That means that my ISP can't know what I say to people, or what people say to me. Trust isn't really an issue here. Pretty much everybody else uses an unencrypted connection to ther IM server.
Re:This is important, but... (Score:2)
Trusting the cert does matter. Because it is an identification of a policy. You acknowledge as much when you say that Verisign was presented with "documentation that identified him as John Doe".
I agree that this matters for commerce. But I disagree with your comment that it doesn't matter for much else.
You, for example, use a self-signed cert to talk with your SSL based Jabber server. Why do you do this? Because you trust the cert. You trust that it was signed by someone that won't let your Jabber server be spoofed by a man in the middle. In this case, that person is you.
But do you think that anyone should trust that unknown CA? Should I, when presented with a CA that I don't know the policy of simply accept the cert? No, of course not, to do so would allow people to read my IM stream. Do I care about this less than my back account, sure, but not a ton less. My credit cards are insured against fraud, so what do I care if someone steals them. Heck, that happened to me just last year.
I agree that your self-signed cert protects you against people snooping your connection. I just don't agree that trust isn't an issue. It is an issue, and you've chosen to trust yourself as a CA.
Re:This is important, but... (Score:1)
Unencrypted connection:
Data transferred as clear text. It can be snooped easily.
Encrypted with self-signed cert:
Data encrypted with SSL, but no signature from Verisign.
Encrypted with signed cert:
Data encrypted with SSL, with a Verisign signature.
What's the difference between those two? That Verisign claims to know who that guy is. Does it do me any good? Not much, probably. I could trust Verisign to check that the certificate includes the real name and location of the server's owner, so that I could say, try to sue him if he decides to log all my messages and put them on his site. Or maybe they could revoke his cert, which they most certainly won't do. After all, how do I prove that the embarrassing log published on foo.com is mine? There's no sure way for me to prove it.
This probably won't do me much good, however. Suing somebody in another country, whose server I used without any kind of agreement (even clickthrough one) could be complicated. And I could do that without Verisign anyway, I'd just have to hope that the whois info for the domain name lists the right name and address.
I think you're a bit confused about what a 'signed by Verisign' cert means. It means that Versign says it knows the cert's owner. It's the same thing as if your friend Fred comes to your friend Joe with a piece of paper signed by you, to prove that he's somebody you trust. This has absolutely nothing to do with the effectiveness of the encryption itself.
Trusting a random CA has the same effect as Fred deciding to trust Joe when he gives him a letter signed by some random person he never heard about. But again, this doesn't have any influence on Fred's and Joe's ability to have a private talk.
For people to be able to read your IM stream, one of these things should happen: The encryption is broken, the encryption is brute forced, the server's private key is compromised. That last option is the most likely, and is archieved by breaking into the server, or the owner giving his private key to somebody else. Verisign's signature doesn't matter at all for this.
Re:This is important, but... (Score:2)
This isn't true. There is a third option, I've mentioned it a few times. A man in the middle attack. This is why the trustworthiness of the CA is important.
If you can't trust the CA then I can get a cert signed (or sign one myself with my CA) and position myself between you and your jabber server. When you try to connect to the jabber server you instead connect to me, I see the text in plaintext because the channel was encrypted using the cert that I provided you. I then turn around and contact the real jabber server and forward the traffic. Thus, to you it looks like you've connected directly, but I've managed to read the entire stream. This occured because the CA wasn't trustworthy and you trusted it anyway.
You keep focusing on the stream after it's been established. I agree, any cert, signed or not by any CA is sufficient to encrypt a channel. It is not, however, enough to *secure* a channel. For that you need to better identify the holder, which is were trusting the CA comes in.
Re:This is important, but... (Score:1)
seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe
A second option is that you break into my jabber server, take the cert, and use that for your attack. This should work as long as the Common Name matches your domain name. Then, the program might be brain damaged and not check that at all.
A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server. If you get in the middle, the cert will be different, signed or not, and I will be warned. This is how SSH works, for example, if I connect to a system whose key changed I will get warned. Knowing the fingerprint of the cert can be good enough as well to determine that you're connecting to the right server.
While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine, and a self-signed cert isn't completely insecure either.
Re:This is important, but... (Score:2)
seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe
While this is all true, it doesn't for a moment have anything to do with the issue at hand, whether or not you the CA signing a cert must be trusted. I never asserted that the signing CA was the *only* thing that must be trusted. It is, however, part of the chain.
In your example, the user must also be trusted to connect to who they want to. seerver.com was correctly identified and the user errored in his typing. The user can still trust that seerver.com is who versign says it is.
A second option is that you break into my jabber server, take the cert, and use that for your attack.
Yes, this is a point where PKI is weaker than some other approaches. It too, however, is orthogonal to whether or not the CA must be trusted.
A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server.
Strictly speaking I claim that the CA must be trusted. I've also argued that there should be a system by which people can more easily gage whether or not to trust a CA. I've not said that a signed cert was, a priori, untrustable. In fact, as in one of you examples I think, a self-signed cert *can* be better because you know that no one spoofed verisign. If they spoof you, however, then the issue remains the same. The CA must be trusted.
While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine
Agreed. It is, as I say above, an essential building block. Without faith in the CA the entire foundation crumbles.
Why? (Score:4, Insightful)
Just follow the instructions that come with OPEN SSL or MOD_SSL.
Why is it that slashdot found it 'news' worthy?
Re:Why? (Score:1)
I find it hard to believe that the book 'Sappers for Dummies' would appear on the shelves any time soon.
I was hoping they went further (Score:3, Informative)
I can give you more help right here and clear up some stuff they glossed over. First, a certificate is not a public key, but it includes the public key, and it is signed by the private key of the Certificate Authority (CA). In the example, a 'root' or self-signed certificate is created. The private key is typically password protected when it is stored (you can see it prompting for that password in the script).
He doesn't show you what you have to do to create the '.csr' file that is used to create the actual site certificate, but this is what is called the Certificate Request. Also, the '.key' file should be created in a separate step. The process is that when someone wants a certificate, they generate a request on their computer that includes all the 'name' information (as displayed in article) and the public key. The private key is generated at the same time, but it should never leave the site generating the request, and additional steps should be taken to protect it from being exposed. The article implies that the key pair is generated by the command given, but I don't think it is (a separate step is needed to create the .csr file, and it should be created then).
A few more notes: your new '.crt' (the certificate) file will show up in 'newcerts' (if not, then 'certs'), the 'serial' file is the serial number of the next (or last) cert issued, and the 'crl' subdir is for the "Certificate Revocation List" all CAs should have one, and it should list all the certificates issued by this authority that have been revoked (by serial number, I think). AFAIK, this is the biggest hole in the process. To correctly verify the validity of a cert, you should always check the cert's serial number against the CRL, but where to you get the CRL? There must be a standard way to get the current CRL from a CA, but does a browser or other client have any function to get it before validating a certificate? Nothing I've seen indicates that clients do this so I doubt whether revocation is ever effective in a practical sense.
Now, what would be really cool is if someone wrapped the functions to create a certificate request with a few web pages and provided a howto describing how to set this up and really run your own CA. If I was doing it, I would keep the CAs private key on external media (a floppy or CD/R), and only put it in the system when I need it to sign certs and CRLs. Isolating the system you use for this is better, but you do still have to get the requests in and the certs or CRLs out.
One final comment. It is just about impossible to actually protect the private key for a typical web server. Or at least protect it from root exploits. This is because you have to either not use a password so that your web server can restart without a password, or have some script that provides the password on startup of the web server. The only other choice is to have someone actually type it whenever a server needs to be restarted, and I don't have to point out here what a pain this would be for a big server farm.
Weak (Score:4, Informative)
Howard? (Score:1)
Are you there Howard?
Tekeli-li! Tekeli-li!
All hail Discordia!
Feh, sorry this was so lame, I couldn't think of anything really funny. I just couldn't resist after seeing the example names, locations, etc. he used.