When Is a Self-Signed SSL Certificate Acceptable?

UltraLoser writes "When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?"

Comments

Always.

[fyngyrz]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

Re:Always.

[jamesh]

Can you cite any examples of a case where a certificate has been subverted in this way?

And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?

I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.

Re:Always.

[jolyonr]

I totally agree - The internet would be FAR more secure if there was a way of using self-signed certificates without browser warnings.

But the certificate vendors have a licence to print money and abuse it horrifically.

For example, a certificate for a domain www.example.com costs a fraction of what a certificate for a wildcard *.example.com would cost. What extra work do they have to do for that extra money?

ALL sites would be more secure with a self-signed certificate than plain HTTP. But self-signed certificates scare the crap out of visitors with their alarmist warnings. If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".

So. I say get rid of the self-signed warnings from all browsers, they do far more harm than good. Instead, make it clear on the browser with colouring, icons, whatever, whether the site has a verified certificate from a CA, or it does not (in the case of self-certs or HTTP).

Jolyon

Re:Always.

[Anonymous Coward]

The internet would be FAR more secure if there was a way of using self-signed certificates without browser warnings So exchange certificates manually with the self-signer that you trust (perhaps in person) and import into your browser manually?

Re:Always.

[jamesh]

ALL sites would be more secure with a self-signed certificate than plain HTTP. But self-signed certificates scare the crap out of visitors with their alarmist warnings. If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".

Being the internet, i'm not quite sure that this isn't sarcasm, but i'm going to pretend it isn't.

Encryption is only a small part of the idea of certificates. The main part is that it gives you, the user, some idea that the web site you are typing your credentials into is who you think it is (eg your bank) and isn't someone else pretending to be your bank.

Encryption is all well and good, but a simple keystroke logger subverts all encryption on the wire, so it doesn't add that much value.

If your bank had a self signed cert, I could create a self signed cert that looked similar enough that most people couldn't spot the difference, and then I could fiddle with the dns settings on the internet cafe that I run (i don't really run an internet cafe, just go along with me), and make you log into my pretend bank website instead. I wouldn't need to do anything to the laptop you brought with you to pull this off.

Look up 'man in the middle' attack if you want to know more.

(or just ignore me if you were being sarcastic and I completely missed the point :)

Re:Always.

[Anonymous Coward]

Rubbish. Self signed certificates provide no guarantees of protection whatsoever if the internet is the only way you're contacting the company. Not even protection through encryption. Using self signed certs, if the initial certificate is man in the middled the encryption is broken. PKI fixes that - using a CA ensures that if you're speaking to https://www.google.com/ and the certificate is signed then you are speaking to https://www.google.com and are not being man in the middled.

Re:Always.

[Yvanhoe]

Am I saying something stupid or aren't company like Verisign providing a good way of preventing people doing man in the middle attacks on SSL ? Agreed, it is far from perfect, but with a self-signed certificate, what is to prevent a clever sysadmin to do mitm attacks ?

Re:Always.

[dreamglider]

Certain web-hosting control panels support multiple links through which you can gain access. The server IP address, the customer domain or the server hostname can be used for logging in and in that case the certificate cannot apply for all hosts. Some of the customers are used to logging in using either of the links and the only solution is to force a redirection which causes a small rebellion. In this case a self-signed certificate saves the day at the expense of browser warning.

Re:Always.

[pairo]

The same argument can be said about any kind of identification method. Any form of ID can be forged, the documents presented to get one can be forged, so I don't really see the point in singling out SSL.

Re:Always.

[squiggleslash]

SSL certificates perform two functions: they verify the credentials of the website you're connecting to, and they provide a secure key for communications between the webserver and you. The reason we combine the two into one certificate is to make man-in-the-middle attacks more difficult. As you suggest, there are ways to compromise the SSL system, however they require you attack in one of four specific places:

1. You compromise the web browser, providing a bogus list of authorities. Your web browser maker becomes liable in that instance.
2. You compromise the SSL certificate authority, creating a bogus certificate signed by the CA. In this instance, the authority is liable
3. You compromise the certificate holder, stealing the legitimate private certificate and redirecting traffic to and from their servers to your own (or hacking into their website to transfer the information to you.) In this case, the holder is liable
4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

At this point it should be obvious what the SSL certificate system provides you with, which is a clear chain of responsibility for breaches in security. Simply sticking a box between a client victim and server victim is not enough, you have to actively compromise one of the four groups above in order to spy on secured traffic. This creates incentives for each group to keep their part of the chain of accountability secure, and it ensures there's a starting point should there be a breach anyway.

Given the difficulty of sending legitimate certificates directly to participants on a mass scale, the CA system is about as secure as we're going to get, and while it's not perfect, that's not a legitimate reason to treat it equally with unsigned certificates. The chain of accountability makes a difference in terms of how you can recover from security breaches, and the likelihood of there being a breach in the first place.

Re:Always.

[chowells]

I don't know of any instances of SSL certificates being subverted in the way described by the GP, but there are instances of phishing sites using correct-looking certificates, such as http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html

"By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website"

Not very easily, but you can use two factor authentication to make sure that even if scammers find out the static username, password, and whatever, it's useless without a second bit of information generated by an electronic device. So the device generates a pin number which is based on time, or generated in a sequence. I have used Cryptocards in the past - they can generate a 7 digit pin number which is valid for one time only - the server knows the order that the card should generate the pin and it can be easily tied into existing infrastructure using by authing using RADIUS. Some UK banks have sent out devices which you need to insert the debit card into in order to generate the code. It's far less likely that the scammer is going to have the debit card, *and* the electronic device, *and* the static username/password.

Re:Always.

[spottedkangaroo]

I disagree 50%. In practice, this is correct, but in theory it is not.

Theoretically, the CA is actually checking the identity of the orgs they sell certs to. Most actually do this to a limited extent.

Also, each of the CAs keeps a revocation list for certificates that got out of reach. In order for someone to use the certificate illegitimately, they have to gain control of the domain name *and* the certificate -- or simply the web-server I suppose.

If no major security breach is *currently* in progress, but one happened in the past, theoretically, you could simply revoke the certificate and get a new one.

The revocation works, but the problem is that nobody actually checks the revocation lists. I was going to link to it, but presently I can't even find the CRL for verisign...

CRL (knowledge)

Perhaps I'm just wrong and the CRL is built into my browser... I don't think so. I seem to recall actually clicking on a bunch of them to tell firefox to go check them nightly.

Yeah, in ff3 it's prefs->advanced->encryption->[revocation lists] -- mine is empty. Heh. Fat lotta good that does.

Re:Always.

[EkriirkE]

They don't/can't protect from man-in-the-middle, they simply provide an accepted known signature that tells the browser that the site('s cert) is verified authentic, vs, say, a DNS hijack with a X-signed (self or otherwise) cert that, unless alerted about funny goings-on, a user would see that security blanket of a lock icon and submit personal info.

Ex: www.ebay.com gets hijacked, the jackers don't have the true private cert, so they create their own. The browser doesn't recognize the granter as a CA it alerts and warns, etc. A small fraction of personal data gets protected - i say small because i think most of the idiots in the inter tubes would just continue on their merry way "Goddamnit, get me to ebay already" *OK* *Yes* *Accept*

Re:Always.

[spottedkangaroo]

For casual uses, you can get a really basic cert at godaddy for $10. I fail to see why that's so bad. The CAs really do check your identity for the $100 certs and that takes personnel and resources. I fail to see why that's so bad.

Re:Always.

[the_womble]

I doubt that precise attack has been used, but:

1) SSL certificates do get issued to phishing sites
2) Some banks have login forms on un-encrypted pages

see: http://news.netcraft.com/archives/2005/12/28/more_than_450_phishing_attacks_used_ssl_in_2005.html and http://it.slashdot.org/article.pl?sid=06/02/13/2143251

Re:Always.

[Anonymous Coward]

Can you cite any examples of a case where a certificate has been subverted in this way?

There are many, mostly not published, but probably the most important one which is publically know, because you could have done anything you wanted with it to most of the computers in the world, is this one. Note that the posting is actually about ongoing security problems related to the hole.

Second in importance to that are the many certificates created with debian for which the private key is insufficiently secure and can be derived from the public key.

You should note, that even though there have been such issues, I belive that no SSL warantee has payed out ever, which gives you some idea how much they are really worth.

Re:Always.

[bpkiwi]

My bank txts a one time authentication code to my phone for any transaction that involves money leaving my accounts (transfers, setting up direct debits, etc). I've always considered it an elegant solution, not foolproof, but few systems are.

Re:Always.

[William Robinson]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

IMHO, No. It does provide many other features including identification of the two machines talking to each other.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Again, IMHO, wrong. You can not take certificate issued to one party and, use it on other server, and make that server pretend as original server.

Digital certificates contain a lot of information including public key of the machine you are interested to communicate. Unless you get hold of private key of the machine in question, that certificate is useless on any other machine. And if you have enough access to the machine to steal private key, the security of machine is already compromised, no need to blame Digital Certificates.

If it would not have been this way, anybody would have been billionaire, using man-in-middle attack, by installing a machine in between client and server.

Self signed certificate are useful as test tool, before you are satisfied with your setup, and before you decide to invest in a globally acceptable Digital Certificate signed by a good CA like Verisign or Thwate.

Correct me if I am wrong:)

Re:Always.

[TractorBarry]

> 4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

I think point 4 should really read:

"4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the *users operating system* is at fault."

Re:Always.

[fyngyrz]

Encryption is only a small part of the idea of certificates. The main part is that it gives you, the user, some idea that the web site you are typing your credentials into is who you think it is (eg your bank) and isn't someone else pretending to be your bank.

This is utter nonsense. Either you have been scammed, or you are a scammer.

Let me tell you what a certificate does in its typical web application. It allows you to create an encrypted conversation with the webserver. At the time the certificate was issued, the cert "authority" required money and that you generate what is called a "certificate request", which is an entirely self-generated document containing nothing of interest or particular security. Typically a company name, an address, that sort of thing. Once they have this, they may (or may not) elect to call a phone number you give them and have you record your voice saying your name or some equally insecure thing. At that point, they issue you the certificate.

Once the certificate is issued, it is installed where the webserver software can find it, and if done correctly (not difficult), the webserver will now allow https as well as http, and, because the certificate was issued by an (cough) authority, your browser will not complain.

Because there is literally no after-the-fact checking, you have no way of knowing, other than reputation (which has NOTHING to do with certificates, but with behavior) if you are dealing with a reputable merchant, or hackerboy69. There's nothing stopping hackerboy69 from *legitimately* getting a certificate from a cert authority that gives him ownership of "trusted-e-commerce.com" or some such horsepucky. He can set up a business, operate long enough to esablish trust, and then hose you. Certificate purring along perfectly 100% of the time.

Presuming the victim site is a reputable one, any time after the cert is installed, any rooting attack on the webserver - of which there are endless varieties - that succeeds, will give the attacker complete control over (a) the webserver, (b) the certificate, (c) the ability to enter into an encrypted conversation with your browser.

There's no need for a "man in the middle" attack, nor is there any need for you, as the consumer, to do anything differently. You're simply hosed. You may think that you're talking to secure-as-heck.com, but in reality, you're talking to hacker-boy-69, who has pwned secure-as-heck.com, and who is now gleefully collecting your information.

So why bother? Because the server takeovers are rare; it ranges from fairly easy to difficult to do, but once done, the work to make the server act normal, but actually steal info, that takes more work. Work that is beyond most script kiddies. But again, this has NOTHING to do with the certificate, only with the security of the site in question. If it gets hacked, you're hosed. Doesn't matter if the hack is through the net or via some employee using the root password some dunce taped to the front of the server rack.

The reason that certificates have value is because when you talk to a website, your packets go all over the place as they travel back and forth between the two parties, and a lot of people and machines have a chance to look them over. SSL conversations are about a zillion times harder to do that to -- they read back as garbage -- so people and machines tend to go for the low-hanging fruit instead, the tons of non-encrypted messages that cross the net. Encryption *is* good. I'd much rather not give a credit card number, expiration date, and CCV code in the clear. But I'm under no illusion that I've been protected from anything except during the trip between me and the server I'm talking to, which I hope, but cannot ever prove, is the one I *want* to be talking to.

Once connected to the server, you have to make the same set of assumptions you do in a brick and mortar store. You have to assume the handsome guy behind the counter belongs there

Re:Always.

[vrillusions]

Remember the story not too long ago about a XSS vulnerability that essentially let you display your own content on an EV certified SSL page? Even a $500+ certificate can't protect against buggy sites. One of the bigger annoyances with firefox 3 is what happens when you go to a site with a certificate that is not valid (self-signed, untrusted CA, expired, etc). You see a page styled similar to the server not found messages. You then have to click on like 4 things with one of them saying that its really bad to do this, etc before you can continue. The time where "valid" certificates I'd encourage are for sites that do payments in some way. Imagine if your bank was suddenly using a self signed cert for login? I've used http://cacert.org/ for years now for the various admin sections of sites. Browsers still don't recognize it as a real ca but adding them is trivial and they are listed in the latest editions of most Linux distros. Its nice not having to add exceptions for all these certs, but can't make self signed ones that last 10 years either

Re:Always.

[Anonymous Coward]

But they don't tell you you are connecting to the site you intend to.
There is no accountability. Are you suggesting I can successfully sue Verisign because I get suckered into visiting a site with a certificate signed by Verisign that looks similar to some other site I am used to visiting?
We would be much better off if browsers saved the certificates of each site we visited and let us know when we went to a site we hadn't visited before or when the certificate of a site we had visited had changed. In those cases information about the certificates could be displayed including information about CAs that had signed the certificate.
The current system is a protection scam that serves the CAs (mostly Verisign) and the browser manufacturers.

Re:Always.

[fyngyrz]

...using a CA ensures that if you're speaking to https://www.google.com/ and the certificate is signed then you are speaking to https://www.google.com/

No. It just ensures you're out some fees. It does not ensure you're talking to a server that legitimately hosts google.com, or to any particular IP, even.

In order to hose you, all I need to do is direct your browser to a new IP where I have a server set up to respond as www.google.com, with a certificate to match which I got from my brother, who works at google, or my sister, who quietly and non-destructively (she's too smart to be interested in showing she's been there) got root on some of google's https-delivery hardware.

I can redirect your browser as required by hacking your hosts file right on your computer, I can do it by hacking the nameserver at your ISP, or, I can skip all that trouble by replacing your firefox with a version that shows *you* "google.com" in the toolbar while I have it connect to "oh-you-are-so-bloody-hosed.com." I can also replace your trusted certificates, or compromise that whole handshake from ever working at all. Remember, since I"m going after your info, all I have to do is make it LOOK like it's secure; it doesn't actually have to be. Firefox being open source, this isn't exactly what I'd call a difficult attack, either.

Cert authorities can't guarantee you any service you can't guarantee yourself. Not one stinking thing. Well, other than if you are legitimate, that you'll be out some money or the connivance with the browser manufacturers will scare the living heck out of any consumer who connects to your self-signed certificate, so you really have to get one from them.

Re:Always.

[INT_QRK]

So, let's examine the facts of the case: some shady characters operating a shady business request that you to accept their self-signed certificates as a exception to a security best-practice rules set because they don't want their identity information published to a reputable certificate authority. The question is whether this is a good idea since the self signed certificate is a valid indicator of the identity of the site. The answer is, sure! But, with the caveat that you are willing to accept the risk of dealing with the disreputable business whose identity you have validly ascertained. So, let's plot that one on the old risk cube, shall we? Consequence: Cost to defend $1M law suite by infringed copyright plaintiff: ~$300/hour attorneys' fees at a very nominal 100 hours in meetings, filings, and court time = $30,000 // Probability: .5 Go for it, genius!

Re:Always.

[jellomizer]

This is slashdot anything dealing with spending money and a company making profit is bad. Yet they will complain that their salaries are too low, and have hard time finding job.

Re:Always.

[jamesh]

Not very easily, but you can use two factor authentication to make sure that even if scammers find out the static username, password

I've got one of these for my banking, and have had it for a few years now. I've also implemented rsa tags on a clients terminal server. And yes, they do solve a lot of problem, especially clients being less then perfect with their password complexity.

Re:Always.

[arcade]

I think you've misunderstood it (or I've not read what you said close enough).

You are Alice. You want to talk to Bob's website: www.example.com

I'm Evel (Hi, I'm male, can't use Even then ;) - and I by chance control your upstream.

Alice -> home network -> ISP (Evel) -> Bob.

Now, you try to connect to www.example.com, and he has got a signed certificate. I don't care about that, and insert my own certificate generated nicely for www.example.com . You get a browser warning - and since you know that Bob has a signed certificate, you know something fishy is about. You will still be communicating through an encrypted channel, but you're going to MY box, with MY certificate, talking to ME. I on the other hand proxy (decrypt, reencrypt -proxy) the requests to Bob. For you, everything looks normal - but I am listening in on the conversation.

Now, say that we didn't have signed certificates. You would not get a browser warning. You've reinstalled your computer, and you don't have Bob's certificate laying around, nor his certificates fingerprint. You access his site, you don't get a warning, and heeey - you don't even have the opportunity to suspect that I'm listening in.

That's the man in the middle we're talking about. Somebody intercepting the traffic, giving you a fake certificate, and using a proxy like that. That's the only thing SSL Certificate Authorities are there to prevent. Nothing else. They've tried to create an additional revenue stream by having 'high class' certificates with extra checking and yaddi-yaddi - but that of course is a nice little scam on their part.

Re:Always.

[terminal.dk]

Basicly, if you trust the included root certs, then you basicly trust that some person who installed the certificate on the site at one point had access to an e-mail address on the domain, or something like that. It guarantees nothing.

Self-signed certificates lets the user decide if he want to trust the site, and the user should be given a warning when the certificate changes, i.e. man-in-the-middle.

I would say self-signed are better. But they MUST match the domain name.

Re:Always.

[jamesh]

1) SSL certificates do get issued to phishing sites

I figured that would probably happen, but i'd never actually seen it. I don't make a habit of deliberately visiting phishing sites though.

2) Some banks have login forms on un-encrypted pages

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.

I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.

Re:Always.

[Nursie]

But there you're solving a completely different problem!

The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.

The electronic pad and/or card are there to assure the bank that you are who you say you are.

Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.

IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.

Re:Always.

[hey!]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

If that is true, then they have limited utility for that too. If certificates are zero good for verifying identity, then they can't protect against man in the middle attacks.

To answer the original question, a self-signed certificate is just as good as a Verisign signed certificate for anything if you have some independent way of verifying its authenticity. You can call the other guy on the phone and ask him to read the fingerprint, for example. In fact, it's arguably a tad better if have a self-signed certificate and a private means of verifying it, because Verisign is yet another party you have to trust. If I was Al Qaeda, I would't trust Verisign not to cooperate with the NSA.

The certificate authority's role is to allow two parties to provide a form identity for a party (or pair of parties) without those parties needing some independent channel for verification. Verisign is the independent verification.

You need an authority signed certificate for things like "drive by" web business. You don't want everybody ordering stuff from your web site to call you on the phone. I wouldn't bother paying for a signed certificate for any kind of private communication, for example an intranet, or a private website for my friends, although I'm sure Verisign will be happy to sell me one.

Of course, a signed certificate is only as good as (a) the security of organization creating the certificate, (b) the security of the signing authority and (c) the security of the "root certificates" on the user's machine. But there's nothing you can do about a subverted user machine using any technology. For private use, since the certificate is no better than your own practices, it makes no sense to pay for a Verisign certificate. It's not magic pixie dust that makes your certificate secure.

But, for providing some level of identity documentation between two unfamiliar parties, companies like Verisign provide a valuable service. Granted, it is to some degree a license to print money, but if the cost to you for providing verification exceeds what Verisign charges, then it makes sense to pay them. In return, Verisign has to safeguard its own keys and signing procedures, which is not quite a trivial as it sounds, given the value a black hat could gain by getting control of them.

Bottom line: self-sign a certificate if the cost of verifying the certificate (including the costs incurred by people who don't bother) is less than what the authority charges. A second situation where self-signed certificates are better is when you have special reasons not to trust any third party authority, and thus are willing to do the work of authenticating certificates yourself.

Re:Always.

[Nursie]

Right, so the problem is user stupidity and education, not SSL.

Re:Always.

[Anonymous Coward]

If your suckered into visiting a site with a similar certificate, then that's your problem. You, sir, are a scammers dream.

If you think that prompting users with a list of certificates is a good way to help mom & pop users beat internet scams, then please pay £1000 to authorise the transaction of 1'000'000'000 USD to your account:

ISBN: WHATTHEFUCKAREYOUON
Bank: IDIOT

Re:Always.

[fyngyrz]

You are Alice. You want to talk to Bob's website: www.example.com

I'm Evel - and I have hacked Alice's computer, compromising anything I need to, from her certificate collection to her browser to her hosts file or all of the above.

Alice ->[her browser hums a happy song] home network -> Evel [collects her CC info, etc., moves to island with hot chicks and rum drinks.] Mind you a keylogger would be enough, but just for fun...

Alice is not safe from attacks. Not with a certificate, and not without one. End of story.

However: If Alice talks to a legitimate merchant, and no one has hacked anything, then the conversation between her and the other end is very difficult to break into, moreso than her computer, I might add. Which is the same advantage you would have had with self-signed certificates. The ONLY time you're safe is when you've not been hacked. To say that because ONE hack has been deterred -- the MITM attack -- the user should feel safe... I'm not buying it. It is as meaningless as saying you're safe because one out of a thousand vulnerabilities in your browser have been patched. You're not safe until there are no vulnerabilities; consequently, you're not safe. Period.

Re:Always.

[StartCom]

You have no clue!

Re:Always.

[Nursie]

"In order to hose you, all I need to do is direct your browser to a new IP where I have a server set up to respond as www.google.com, with a certificate to match which I got from my brother, who works at google, or my sister, who quietly and non-destructively (she's too smart to be interested in showing she's been there) got root on some of google's https-delivery hardware."

Right, so by this time, you've not only compromised my ISP DNS servers or my home computer, but you've compromised Google as well.

If you have access to all these systems then why the fuck do you care about SSL?

This is non-trivial and a highly organised criminal gang like the one you're part of is not the problem SSL is trying to fix.

Re:Always.

[Confuse Ed]

re: They do not, and never been able to, provide any verification of who is on either end.

They do provide a _little_ verification - so long as you permanently remember the certificate it verifies that whoever is at the other end of the connection on subsequent sessions is the same as whoever is at the other end now (so long as they've kept their private cert suitably secure)

aside: is there _any_ way of ever verifying 'who' someone / something is beyond 'you are the same person that I saw that other time' or 'you are the same person that someone intermediary claims they saw in the past'-> which if you follow it through leads to a better understanding of what a person's identity is and is not, and what you can/can't achieve when requiring people to present 'identification' for security purposes - and a misunderstanding of which leads to a lot of silly security 'theatre'

Re:Always.

[I cant believe its n]

Can you cite any examples of a case where a certificate has been subverted in this way?

Why would he need this for his argument? Your argument goes like this: Name one person who has been attacked by a bear. If you cant, then nobody has ever been attacked by a bear.

I understand that it may be a rare and for the average person an unlikely event, but none the less, certificates can become compromised one way or another.

I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.

Do you absolutely trust Verisign? Do you trust Verisign not to cooperate with the US government? Would you trust a new certificate authority in Russia, and would you trust them not to cooperate with the Russian government? Before you say that there is no such Russian authority, remember that the rest of the world relies on US certificate authorities.

Re:Always.

[ArsenneLupin]

For example, a certificate for a domain www.example.com costs a fraction of what a certificate for a wildcard *.example.com would cost. What extra work do they have to do for that extra money? Right on. I know a guy who works for a certification authority, and indeed, he confirmed me that potential for additional profit is the only reason why wildcard certificates cost more or are discouraged altogether.

Re:Always.

[Nursie]

"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."

This is one of the most stupid things I've read all year and clearly comes from someone that knows absolutely FUCK ALL about SSL/TLS.

SSL certificates provide authentication that the server you are talking to is the one the certificate was issued to. They provide you with a level of trust. Not absolute trust, but they tell you this one thing -

The person I think I'm talking to, the CA agrees that it's them.

SSL certificates do NOT provide encryption. Asymmetric encryption is computationally expensive. In SOME SSL/TLS cipher suites they may provide a key exchange mechanism. However this is not always the case and we have Diffie-Hellman (DH and DHE) style shared-secret mechanisms for that. AES or 3DES are most often used for the actual encryption. SSL/TLS also provides for data integrity checking using MD5 or SHA hashes. You don't have to have encryption at all, in some circumstances the authentication and integrity are what you're after.

Anyway, I just thought I'd point out that your post there is fucking nonsense.

Re:Always.

[bloodninja]

1. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

No, in that case Fedora is at fault. Wait, that doesn't happen to Fedora machines? Then whatever OS does allow this is at fault.

Re:Always.

[wbormann]

An X.509 certificate is a binding of a subject name to a public key. *Everything* in an X.509 certificate is public information.

It does not provide encryption - just the information used by software that provides services in a public key infrastructure.

To the meat of the question: if you know what you're doing, it is appropriate to use self-signed certificates in internal applications that need to use public key encryption. This would include, but not be limited to, situations where internal/intranet services need to communicate to other intranet services. I would not recommend it for public services (like https:, for example). The reason is simple: there would be no mechanism for the client to verify the authenticity of the server certificate.

Re:Always.

[Devout_IPUite]

Maybe we should like CA certs because it deters one attack, MITM. Yes, Alice can still be hacked, yes Bob's site can still be hacked, but detering MITM is one fewer avenue Evel has to get to the Bahamas. Using self-signed certs makes MITM easier than I'd like. The harder we can make it to steal our money, the fewer people will do it (simple economics here, if there's a higher knowledge/time cost to steal a dollar fewer people will do it).

Re:Always.

[tim_olsen]

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

Yep. If you read the fine print they admit that they cannot vouch for the identity of the website. From their end-user agreement (downcased to bypass /. filters):

6. disclaimer of warranty. ... verisign makes no representation or
warranty to any person that any ca or user to which it has issued a
certificate in the verisign secure server hierarchy is in fact the
person or organization it claims to be in the information supplied to
verisign or that any ca or user is in fact the person or organization
listed in the certificate. verisign makes no assurances of the
accuracy, authenticity, integrity, or reliability of information
contained in certificates or in other certificate status mechanisms
compiled, published or disseminated by verisign, or of the results of
cryptographic methods implemented in connection with such
certificates. ...

Re:Always.

[Anonymous Coward]

You need to think more and write less. The function of a certificate is authentication. It's not perfect, but it's not useless either. Without authentication many types of attacks are possible which are not possible with authentication. The circumvention of the authentication stage requires different and generally more elaborate techniques. Authentication is not just protection against someone who sits between you and the web server, it's also protection against all sorts of address spoofing, unless combined with the attacker compromising the private key. That, btw, can be avoided even in the case of a root compromise on the web server. The SSL endpoint does not need to be the web server, and even if it is, the server can "outsource" the handling of the private key to secure hardware.

Re:Always.

[fyngyrz]

[certs] ...verify the credentials of the website you're connecting to

No. They don't. They match a stored file against a protocol using other stored files and a program that knows that protocol. That stored file is not a "credential" in the sense of being something you should trust. No more than any copyable, fakable, transportable ID should be trusted, anyway. It's simply a key. A key that can be copied. A key that be ignored (by removing or otherwise compromising the locking mechanism in the program.) There is no, repeat no, assurance that you're talking to me if you connect to a server you think, for whatever reason, is mine. If my server has been rooted, that opens up many doors to taking advantage of you, certificate or not. If your computer has been compromised, that opens up many more such doors. In all such cases, what you're verifying is not where you think it is and does not mean what you think it means, and all actions and reactions along the connection you've made are under the control of the compromising agent, again, certificate, or not.

When you connect to a site using a browser's https, what you should be saying to yourself is "look, ma, looks like they have a key, if this dang lock is working." You do not know who "they" is. You do not know if they should have one. You do not know if your locking mechanism is working the way it worked yesterday. You do not even know if the IP you think you're connecting to is the same one you connected to yesterday, name resolution aside. Servers can move in very short order. Legitimately, and otherwise.

What is funny -- ok, well, it's actually sad -- is that the best protected sites tend to be nameservers and hardware with similar roles. Not always, but it takes more savvy to run one than it does to either put up a web site or power up your home computer and begin browsing the net. Technologies that protect us from compromises at those levels are kind of like wearing chain mail to the mall in case someone attacks you with a sword. That's not the real problem. The real problem is the guy who wants to snatch your purse, steal your car, robs your house after you left, etc. Likewise, the real problem with https (for the consumer) is the guy who roots the server you're trying to talk to, or roots your own machine. And as history has shown us, protections against those attacks haven't been proven to be anywhere near sufficient.

Re:Always.

[chriseyre2000]

The slight flaw is that the gadget that is sent out is interchangeable between banks - it adds no extra security other than that supplied by the card. A hypothetical criminal can be expected to have one.

Re:Always.

[Hal_Porter]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

That seems a bit purist to me. I want to go the the bank to transfer some cash. I fire up my browser and the browser checks that the certificate matches the domain. No I guess the bank paid Verisign a fee and Verisign used some secure courier service to send the a CD with the key on it. The bank install it on their servers and stick it in vault.

When I log on I enter a cryptic ID and some data from a hard token and the site shows me my account.

Now for someone to fake this they would need to poison DNS somehow, have a copy of the site certificate, and have access to the database that turns cryptic IDs into bank account numbers. Even then it doesn't help them, because I enter data from a hardtoken, not a pasword. But I've actually seen quite good fakes of sites that only require a password and the only sign they were fake was a warning about the cert not matching the domain.

It's not perfect, but it's not useless. Most real world security is like that actually. If you're alert and your browser warns you that something is hinky, it is useful to you.

Re:Always.

[fyngyrz]

The function of a certificate is encryption

There, fixed that for you.

Re:Always.

[kayditty]

Holy shit! The internet?

Re:Always.

[Thiez]

Oh shut up already. While the operating can certainly help make your computer more secure (or insecure), even the most secure operating system can be crippled by misconfiguration. To be truly secure the operating must disallow misconfiguration, which is undoable and, in my opinion, undesireable.

Re:Always.

[bloodninja]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

For end users, it doesn't even provide that. Users don't know what SSL certs are for, other than the fact that they cause popups and spam (Yes, I've heard users refer to popups for SSL certs as spam. Spam is now a general word for 'annoyance', much as 'virus' is now a general word for 'malware').

Given the opportunity to visit an https enabled site with a popup and an http site without, everyone who does not read /. would choose the latter. For whatever reason, people think that the interwebs are secure and safe and that they can pick their noses and nobody sees them. Pretty colours in the address bar, lock icons, and fucking fireworks won't prevent people from ignoring security. I even had a user remove Firefox3 RC1 from her machine because it would warn her about suspicious websites and not let her continue. Forget that the browser is protecting her, she wants that [background|screensaver|cursor animation] no matter what the cost.

Re:Always.

[Hal_Porter]

SEBanken in Sweden gave out hardtokens. Initially it worked like this. To log on or make a transaction they sent you two 4 digit numbers. You entered a PIN number into the hardtoken to prove to it that you were not an imposter. Then you entered the two numbers and it signed them to give you a four digit number which you then entered into the bank site to make the transation.

Recently they improved it. Rather than two four digit numbers they sent one number which was the amount you were transferring and one which was opaque. So now if a MIM site is intercepting things, they can't change the amount your transferring. And you have to initiate the transfer in the seb site.

Like you say, it's not perfect but it's pretty good.

Re:Always.

[sk8king]

I thought that a couple years [okay, more than a couple] ago, Microsoft had someone [disgruntled employee] register a certificate under their name. Can't find a link, but maybe my memory is faulty.

Re:Always.

[Gewalt]

I don't have mod points today, so I feel compelled to instead reply to this post with a vehement "Hell ya!". I have been trying to convince people for years that a self signed cert is FAR BETTER than no cert at all. But the browsers... they belie the security implications horridly. The browsers themselves are teaching people that no security is better than self managed security, which doesn't do anything good except drive revenue to the Root CAs.

Re:Always.

[camperdave]

The slight flaw is that the gadget that is sent out is interchangeable between banks - it adds no extra security other than that supplied by the card. A hypothetical criminal can be expected to have one.

Well, as I understand it, each of these devices has a unique ID, which is seeded into the number generation algorithm. The criminal's device will be spewing out a different number sequence than mine.

Re:Always.

[Anonymous Coward]

Yawn.

1. Please, try to get a certificate for bankofamerica.com with Verisign or similar. Tell me how that "oh they'll only want to call up a phone number" claim works out for you, today, in 2008.

2. People do not "get root all the time". Maybe you and the people you work with lack the competence to sufficiently protect machines holding critical data, or maybe you can list examples of root being "got" "all the time" on Google, Amazon, Yahoo, etc that it just so happens no-one but yourself knows about... but I think you're just another kid who takes out the "well in theory xyz could happen so it's all pointless!" card.

3. Please explain to your non-tl;dr audience why it would help if I managed to change nameserver entries for www.amazon.com, say. That's right, it wouldn't, unless I've already got root in 2.

But if I've already got root on a server, then I can broadcast all your private data in plain text around the world, and boxes are being rooted "all the time", which means the initial SSL connection was a waste of effort, which means all encryption is pointless omg revelation!!!111oneone0xb0xb\lim_{x\to 0}\frac{\sin x}{x}

You are an idiot.

Re:Always.

[Tony Hoyle]

No they don't. We have a code signing cert. I got it by email - I'm not the owner of the company or anything.. I just looked up the company reg. number and sent them the registered address and they replied with the link to the certificate the same day.

I could have been *anyone* - there was absolutely no real verification.. I literally googled all the information as it was quicker than asking my boss. For this they wanted $200.

Re:Always.

[arcade]

I didn't say the user should feel safe.

The trusted third party _is_ needed to solve the key distribution problem, unless you've got a hell of a lot of resources. This may or may not be something you worry about - but that's it (At least in this mode, they've also got a role to play in digital signatures).

There has, however, been attempts to hack 'user safety' on top of the feature list for trusted third parties. To that I just say: hogwash!

Re:Always.

[Constantine XVI]

Out of curiosity, which bank, and where?

Re:Always.

[growse]

That's the beauty of PKI though. You don't have to trust Verisign - they're not the only root CA out there.

If you decide that you don't trust Verisign, and your bank uses a Verisign cert for their online banking, by extension you don't trust the bank, and should find a new one. I can't think of an example of a situation where you're forced to trust a particular root CA and have zero choice in the matter.

Re:Always.

[gregmac]

Speaking only about the $10 vs $100 certificate - when was the last time you actually looked and checked that a site you were visiting had a "high security" SSL certificate, as opposed to just a certificate that issued no warnings?

Granted, EV certificates at least display the green address bar in current browsers, but it won't be long until all certificates are EV and that it is just as useless as SSL is for identity verification.

I remember applying for an SSL certificate many years ago (1999-ish) and it was a big deal.. had to fax copies of the business license, personal driver's license, etc. to get it approved. Now, you can get a certificate for $10-15, and the whole process takes 5-10 minutes. Eventually CA's will compete on price, and compete on "ease of getting through the process" (eg, less verification), and the whole EV SSL thing will degrade into the $10-15 market you see now for regular SSL.

Re:Always.

[pla]

At this point it should be obvious what the SSL certificate system provides you with, which is a clear chain of responsibility for breaches in security.

You use the word "liability" in a curious manner here, suggesting that you've spent too much time with PHBs (or worse, may count as one yourself - No offense intended, may FSM have mercy on your soul)... Although the corporate world may care who to point the finger at, the rest of us just want to know that www.mybank.com really goes to my bank, and that no one can snoop in on their conversation.

For the former, self-signed certs don't suffice. Although in theory neither do CA-issued certs (you listed four vectors of attack, with the end user themselves as the most likely to fail), they count as the best means of identification commonly available.

For the latter, "identification" doesn't always matter. I don't really care if my "News for Nerds" comes from Slashdot or someone disguised as Slashdot; I do, however, prefer that my employer (which allows reading Slashdot) not have the ability to associate my Slashdot handle with my real identity. Encryption alone will suffice for that, so a self-signed cert would do just fine.


I understand why we would combine those two functions into one mechanism, but people need to understand that self-signed still beats unencrypted HTTP by quite a lot.

Re:Always.

[Anonymous Coward]

So you're saying that sites that use self-signed certs are a big cause of this problem, because they encourage people to ignore the warnings, right?

Re:Always.

[Anonymous Coward]

Nope. The function of the public key is encryption (of the shared key for the symmetric cypher). The function of the certificate is authentication, specifically authentication of the contained public key's ownership by establishing an indirect trust relationship through cryptographic signatures. A self-signed certificate can't provide the latter, so its sole purpose is to pad the public key with useless signatures in order to conform to the SSL protocol, but that is exactly why your browser warns you upon establishing a connection with such a certificate that the identity of the issuer could not be verified: The self-signed certificate does not perform the function that it has in the SSL protocol.

Re:Always.

[Anonymous Coward]

In new versions of FireFox the name of the certified site is shown to the left of the address bar if a site has a valid cert. Why not show the names of the whole chain, if there is a chain?

E.g.

Trusted list|Thawte|Telia AB || http://www.telia.se
instead of just
Telia AB || http://www.telia.se

That way, a self-signed cert would look either as

RedHog || http://redhog.org
or as
TrustedList|RedHog || http://redhog.org
if you have added the cert to your list of trusted certs.

Even better, the first time you see a new site, ask if the user wants to add the cert of it to the list, warning that this won't prove who the site is, only prove that next time you go there, it's the same site.

Re:Always.

[redalien]

No, it's on the card. The device will work on any card, even from different banks. For the crim to be able to duplicate your signature they need the key internal to your card.

Re:Always.

[BadOPCode]

I kind of agree with you. But not so much on the get rid of all warnings on self-signed certificates. But there should be a less-secured encryption method available that won't prompt the users with a dialog that translates to most end-users "Warning this site is trying to download all your personal information and post a email to your boss of the porn sites you visit." I see the validation of the higher secured systems. Two check stops is more secure than one. As three check stops is more secure than two. But there should be a method that would just be for not sending/receiving clear. Hackable most definitely. But it would take a little more effort than what is needed now for putting together someones entire web transactions with a simple packet snooper.

Re:Always.

[arcade]

No.

The function of the KEY is encryption. The function of the certificate is authentication.

Big difference.

Re:Always.

[paskie]

E.g. in CZ, the biggest bank Ceska Sporitelna (subsidiary of Erste Bank) does this and AFAIK many other Czech banks do the same, too.

Re:Always.

[jvale]

2) Some banks have login forms on un-encrypted pages

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.

I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.

If you check the login form's source you'll notice that it is being submitted to an https URL.

Re:Always.

[Anonymous Coward]

so if I use a self signed cert, I reduce the possible vectors of attack from four to three (1, 3 and 4)?

damn! I find this interesting!

sure come screaming MITM, but since MITM can also get valid certs I don't see how you and your authorities and your certs are safer right now!

Re:Always.

[Mjec]

I'm not the GP but my bank does this. It's Commonwealth Bank in Australia. Interestingly it's slogan was for a long time "which bank?"

Re:Always.

[jamesh]

If you check the login form's source you'll notice that it is being submitted to an https URL.

You don't quite get it then. By the time i've hit submit, i've already entered my username and password. It's too late by then to find out that i've just submitted my details to a 'man in the middle'.

Encryption is nice, but the more important value in ssl certs is that they verify who it is that you're talking to.

Re:Always.

[eggoeater]

Exactly!
Go to http://www.wachovia.com/
There's a login on the front page.
Just because the login page is not secured does not mean it's not posted to a secure site.
I use to work for Wachovia; believe me when I say they are quite serious about their IT security, both internally and customer facing.

Re:Always.

[Anonymous Coward]

If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".

This is the default on all major browsers (specifically for form submission), and the vast majority of users turn it off because they get a warning when they search Google. Just what the hell else are the browser makers supposed to do?

Re:Always.

[dfunked]

So if I would overtake some site (MITM, whatever) and issue my own self signed cert, shouldn't there be a warning that this certificate is unknown? That's IMHO the real purpose of the self signed warnings.

Re:Always.

[jamesh]

Your argument goes like this: Name one person who has been attacked by a bear. If you cant, then nobody has ever been attacked by a bear.

No. It doesn't. There is a difference between 'could possibly happen in theory', and 'has happened before'. Bear attacks have happened and there are plenty of examples of such attacks, but if there are no examples of something having happened then it must at least be unlikely, and perhaps has never happened before, in which case it's just speculation.

Anyway, I was more curious about a case study of subverted certificate, it would make an interesting read.

Do you absolutely trust Verisign?

I don't have to. My bank does, and they're the ones who will lose out if my money goes missing because their trust was misplaced. Their instructions to me are to check the certificate before I log in, which I do. I also use a 2nd authentication factor, also as per their recommendations.

Re:Always.

[tonyray]

"2) Some banks have login forms on un-encrypted pages"

The login page can be un-encrypted as long as the data from the form on that page is encrypted before it is sent over the Internet. Said another way, as long as the form action is "https://mybank.com/etc" there is no problem. The only reason some banks encrypt the login page is to make the customer feel good; it doesn't increase their security one iota.

Re:Always.

[hal9000(jr)]

Can you cite any examples of a case where a certificate has been subverted in this way?

Yes. Back in 2001, Verisign issued 3 code signing certificates to people impersonating Microsoft employees.

As others I am sure have already said, the strength of the identity verification is solely based on how the verification is done.

Re:Always.

[naasking]

And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?

Petname Toolbar.

The first connection to a site must always verify the signature using an out-of-band channel. CAs are one type of out-of-band channel, but not the only type. After the initial verification, the petname toolbar saves the signature with a user-specified label, and displays that label everytime you connect to a site with the same signature so you know who you're dealing with. Simple and effective.

Re:Always.

[guruevi]

Nonetheless, it does happen. Usually with wildcard certificates. I used to work for a couple of hosting company and they usually have a wildcard certificate for *.hostingdomain.com. So the spammers get a (usually free trial) package with free SSL certificate and some type of bogus domain like paypal.com.hostingdomain.com and they have a somewhat valid SSL enabled site. And people that click and follow phishing sites are dumb enough to say: it has a keylock in the address bar, it is safe.

Re:Always.

[IntlHarvester]

In most cases, you wouldn't need to compromise the ISP DNS, only the DHCP server the person is using (generally a consumer router). I could see this attack being feasible with a public wireless point or a cybercafe.

Also he is confusing a bunch of different issues in his post in a poor attempt to make a point. Serving up bullshit DNS is a lot easier than getting your brother's friend's sister to give you Google's cert.

Re:Always.

[Rinisari]

'Twould be interesting to see a study of general folks' usage and knowledge of certificates. Since they never see a dialog popup when on an HTTPS site, they may not even know the difference.

Then, disable the certificate error thing and see if any of them notice a difference.

Re:Always.

[Anonymous Coward]

"trust is based on mutuality"

Re:Always.

[naasking]

Certs are very poor authentication tokens. Phishing sites get certs all the time. All they need to do is create a similar looking page, with a valid cert, and you're hosed. How does the cert help you authenticate here?

Re:Always.

[Anonymous Coward]

Maddox knows LaTeX?

Re:Always.

[sYkSh0n3]

And if you just add an s to the http it reloads the page as secure and ff3 gives it a green rating with all their info being avail through the new address bar.

so really all they need to do is change the link to the login page to include the s.

Re:Always.

[darthflo]

There's one problem:
Wachovia tells their users to enter their credentials on the unsecured front page, which then submits to a secure script processing said credentials.
What you might be forgetting: What if I set up interception on my shared WiFi (or somewhere at the backbone of the hypothetical ISP I might be working for) to grab all HTTP requests for / going to r3wec01.wachovia.com and add a tiny bit of JavaScript that, in addition to the page working as it usually does, posts all keypresses to a script of my choosing?
Without access to WB's certificate, I couldn't do that on a properly secured HTTPS site. Thanks to unencrypted HTTP, it's pretty trivial.

Re:Always.

[darthflo]

Yes it does.

Re:Always.

[Anonymous Coward]

Most of them haven't bothered looking for a job because they're too busying "fighting the man" from their basements full of broken computers.

Re:Always.

[Anonymous Coward]

I'm not sure you have a clear understanding of what a certificate does. Of course the certificate can be "controlled" by anyone after it's issued - it's public information. What is not public is the private key associated with the certificate. If that is sufficiently protected by it's owner and the 3rd party CA is trusted, certificates provide authentication. Whether or not you trust Verisign as a CA is a different issue. Self-signed certificates are no more secure than exchanging raw public keys (which is not secure) because no trusted 3rd party certifies the authenticity of either.

Re:Always.

[Silicon Avatar]

I don't think you quite understand.

So long as the form is being submitted via ssl, it doesn't matter what text you put on this otherwise unencrypted page.

The plaintext stays local until you hit submit. At that point, since you are submitting via ssl, the form contents are encrypted.

Re:Always.

[Anonymous Coward]

If the page with the form is not transmitted securely, it can be altered en-route so that it sends your login information anywhere the man-in-the-middle wants. As long as it also sends it to the right site, you'll be none the wiser. In the meantime you've trained people to enter confidential information into http-transmitted pages, so they won't be cautious when the site of someone who does it right is spoofed without encryption.

It's this penny-pinching attitude that most often breaks security. The door is solid steel with five locks, but the window is wide open.

Re:Always.

[duffbeer703]

You really should read and understand more about this before spouting off like some sort of authority.

Encryption by itself is not very useful, as it only operates at the network layer. So some nefarious network user or ISP admin will be unable to read your communications. Big freaking deal.

SSL Certs aren't a silver bullet to save you from fraud, but they do provide a measure of security against attacks like address spoofing or upstream network users proxying your connection. They also provide an audit trail to help establish who is operating the site.

Re:Always.

[naasking]

At this point it should be obvious what the SSL certificate system provides you with, which is a clear chain of responsibility for breaches in security.

So, who is responsible for a phishing attack using a legitimate cert?

You can say 'the user' all you want, but certs themselves are to blame. They are not a usable authentication tool, despite the claims.

Re:Always.

[wasabii]

That is true, but what Verisign and folks have done is given you an authority to contact the licensed owner of the certificate and make your complaint heard, and also the ability to revoke it because of misuse.

Re:Always.

[duffbeer703]

And when you do something nefarious with your signed code, the police will subpoena the CA for the details of your transaction, get your info from the credit card company, and send a cop to your door.

Re:Always.

[darthflo]

So, between 1999-ish and 2008, verification shrunk from "extensive" to 5-10 mins of clickery. Let's, for the sake of rounded numbers, assume that EV SSL will go the same way in the course of five years, from about 2005 to about 2010.
If history does indeed repeat itself, EEV SSL and it's successors will, in the same fashion, have a lifespan of 5 years from "extensive" to 5-10 mins of security. At 18 bits of colour depth per pixel, Apple users have 1.3 Million years of "new" colours for browser vendors to colour the address bar in; most other display makers' customers have 83 Million years (24 bits of depth) left until the address bar color turns SSL-yellow again. Seems fine to me :]

Re:Always.

[wasabii]

Though this has actually prevented a man in the middle attack. If they become a MITM, they have to decrypt and reencrypt data as it flows through. Which means an encrypted connection has to be set up between the client and the MITM. This encrypted connection cannot use the same pk, as it exists only at the bank. Hence, the MITM is thwarted by a big warning that says the site is not trusted.

Re:Always.

[CastrTroy]

It is quite easy to find examples of people attacked by bears. While I don't personally know anybody who was attacked by a bear, I can find many examples of people who were attacked. At this point in time, it's not worth your time to do DNS cache poisoning, or trying to subvert the security of verisign (no matter how easy it may be), because it's all too easy to send out a million emails pretending to be a bank, and getting people to just give up their login and password, into a completely fake site.

Re:Always.

[drinkypoo]

Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to. IMHO this is a MAJOR problem in security.

The solution is legal rather than technical. You have someone to sue if you have no reason to believe that someone might steal your data. In other words, ignorance is the only defense. To flagellate a deceased equine, it's like the OSI claiming to have invented the term "Open Source" - they know they have no leg to stand on, but if they admit it just once then they will be laughed right out of court if they ever do try to register it as their trademark and are challenged. This is the same situation - you have to act like you trust the gas station to provide you with security, and they have to act like they trust the credit card company. As long as they're incompetent, no one can expect them to actually be secure.

As always, the taxpayer foots part of the bill, and the low-end customers tend to split the rest. They are the least valuable customers (individually) and the least likely to vote with their feet.

Re:Always.

[Kiralan]

If the certificate was used to verify identity, I can see your concern on this. However, if it is being used solely for encryption/privacy (piratebay, possibly?), I am depending on the key strength, which I can verify locally, rather than the identity. My priority is the privacy of my SSL connection, rather than the identity of the entity. No coffee yet......

Re:Always.

[Chankama]

Well, the address and other domain/company specific information of the company is ALSO part of the certificate. A certificate authority will/should only sign certificates once it establishes that the signing request comes from a valid representative of the company. Assuming the latter is true, no one ELSE can really be "in control" of the certficate. I mean how can they? Only the company has the private key. The company doesn't even need to give the private key to the CA when they get their certificate signed. The actual certificate is useless to an attacker without the private key. If the attacker wants to create a new certificate with the company's name, then they would somehow need to convince the CA by offline means (phone, fax, in person, letter, etc.) that they are a valid representative of the company and that the CA should sign the new certificate - which the attacker can now use to fool consumers. I think Microsoft revoked a couple of certificates a few years back b/c of this exact problem. Haven't heard issues like this in a while. From the consumers side, it is simply not enough to check that the "yellow padlock" is present in your browser. Go in to the certificate and check if it corresponds to the company that you are trying to do business with! Now to answer the original question, I hate self-signed certificates. When I download Firefox or IE, I am making the assumption that the pre-installed CA certificates are valid. Once you accept the risks involved with downloading a browser from a non-secure site, you really don't want to be exposed to it every time you visit a new site! An attacker can easily make you accept their unsigned certificate over some other unsigned certificate. Especially, with mismatched domains its very difficult to tell. I know companies do that. But, those companies usually have IT staff that have absolutely no education in security.

Re:Always.

[slim]

Certs are very poor authentication tokens.

Maybe so, but poor or not, authentication is their function. You don't need a certificate for encryption.

I sometimes wonder why the designers of SSL mandated a certificate at the server end. I guess they couldn't think of a situation where you'd want to encrypt data to/from a completely arbitrary unauthenticated entity.

Re:Always.

[Anonymous Coward]

The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.

That's not what it does, though.

The only thing it does is to assure you that the bank says they are who Verisign says they are. Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty.

Why should anyone trust Verisign? What reasons do we have to trust them? Not "to not trust them", trust needs to be earned.

If we can't even trust them not to ruin DNS, how can they ever reach the level of trust needed for certificates? Does the word "sitefinder" ring a bell? Verisign has already demonstrated that we can't even trust them not to ruin DNS, and certificates need a much higher level of trust.

Then tell me... If I'm the victim of a MITM-attack, why would I even care if Verisign says that the attacker is my bank or not? He's still going to copy the entire encrypted transactions either way.

Re:Always.

[David_Hart]

The truth of the matter is that certificates used on web sites are indeed only used for encryption. The only reason why companies use Verisign certs (and other commercial certificate services) is because the Verisign CAs are trusted by default by IE, Firefox, etc. Most online customers do not like being inconvenienced by pop-ups when paying for their purchases, etc. SSL certificates are rarely, if ever, used for identification purposes. Even if they were, do you truly believe that users would notice a problem rather than just click on OK?

That being said, there are other certificate types that are used for identification and for which CRLs are important, such as VPN certs.

David

Re:Always.

[brunascle]

Phishing sites get certs all the time.

but they do not get valid certs for for paypal.com. they can only get them for their own domain. and if someone is duped by a phishing site without the right domain, they'll be duped regardless of whether or not it uses SSL.

just like anything other security mechanism, a cert wont help you if you're not paying attention.

Re:Always.

[Bert64]

IF you can spoof mybank.com.au's DNS then you can apply for a certificate to that domain yourself... Most certificate authorities just send you an email to confirm, and if you control the DNS you can control the MX records to ensure you receive that mail.

It may not have been done many times that we know of, but i've not heard of DNS spoofing attacks for such sites either.

Your browser would not know the difference between the certificate for www.mybank.com.au owned by the bank and signed by CA1, and the certificate for www.mybank.com.au owned by evilhacker and signed by CA2.
As for revocation, how exactly does your browser get to know that a particular cert is revoked?

What really should be done, especially in the case of banks where they are already in contact with their customers... The customer has to authenticate to the bank's webserver, but why shouldn't the webserver authenticate to the bank's customer? The way SSH works is good, the user has the public key of the host and verifies it each time they connect, the bank could supply you the public key when you sign up for online banking.

Re:Always.

[yukam]

But then I need every time verify HTML code (including javascript [obsfucation + halting problem!]), to ensure it did not modified by MITM to direct somewhere else.

When login page is https - I'm know that page code did not modified by MITM.

Re:Always.

[drinkypoo]

Technologies that protect us from compromises at those levels are kind of like wearing chain mail to the mall in case someone attacks you with a sword. That's not the real problem.

Actually, it's just like keeping alert and ready to dodge in case someone attacks... er, you know what I mean, what you said. If he's got a broadsword that's probably enough. If he's got a katana you're meat. But you take SOME precaution because people DO get attacked with swords (watch where you're going is probably sufficient) just as DNS has been attacked (successfully!) in the past, and probably will be again in the future because we don't use crypto there.

Re:Always.

[Anonymous Coward]

No, it is you who does not understand. The page into which you enter your login credentials was not protected from being tampered with on the way to your browser. You don't read the source before you enter your credentials, do you?

Re:Always.

[Matje]

no no no, really you don't understand. Since the login page is not encrypted, it may have been changed during transfer to your browser. You'll be sending your user credentials to the evil MITM.

See? since you can't trust the login page it doesn't matter that your username & password are sent using SSL, since you'd be sending them encrypted to the evil MITM.

Re:Always.

[vertinox]

Can you cite any examples of a case where a certificate has been subverted in this way?

I don't think he's talking about subversion. He's talking about the fact that anyone with $900 can buy a cert from verisign regardless of their evil intentions.

His point was that since any malware site or someone who just intends to steal your credit card on a legit looking site could in theory buy a legal cert, that rolling your own is just as trust worthy.

A phishing site would have a problem getting a banks cert, but they could even roll their own with something that says "Signed by Verising" and since the person probaly didn't read the address at the top in the first place they most likley wouldn't bother double clicking on the lock on their browser.

Personally, I wouldn't do financial transactions on a company that rolled their own, but I wouldn't mind just using a website that had rolled their own keys.

Re:Always.

[naasking]

but they do not get valid certs for for paypal.com. they can only get them for their own domain

Sure, which might be for paypa1.com. Did you spot the difference on the first read?

just like anything other security mechanism, a cert wont help you if you're not paying attention.

It has nothing to do with 'paying attention'. The interface for verifying certs is absolutely meaningless to anyone without a strong technical background. Users can't verify a cert even if they wanted to. That's a fatal flaw.

Displaying all the identity info, the CA, etc. is useless to most people. In order to verify that they are talking to the site they intended to talk to, the user has to verify the cert's signature via an out of band channel. The signature is the only part of the cert the user actually cares about.

Once it is verified, you can use the petname toolbar for Firefox and assign a label for that cert. Then, whenever Firefox sees that cert, it display that label, and you know who you're talking to.

That's a properly designed identification system. The current CA-based system is laughably bad by comparison.

Re:Always.

[Anonymous Coward]

ALL sites would be more secure with a self-signed certificate than plain HTTP. But self-signed certificates scare the crap out of visitors with their alarmist warnings. If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".

Encryption doesn't make it secure. Encryption is a tool to provide security but the use of that tool isn't security, they are very different concepts.

All sites would be more secure if your browser wouldn't accept self-signed certificates. If it simply wouldn't let you use https on those sites we'd be better.

Re:Always.

[Anonymous Coward]

The same way you make sure there's no MITM attack when you ssh into a box: you verify the fingerprints.

It's all a question about who you trust. As some other posters noted: blindly trusting the CA-certificates coming with your browser is worse than using self-signed certificates and verifying the fingerprints.

Re:Always.

[EmGooser]

I have to agree with jamesh on this one. Part of the security around having the SSL cert verified off site is it helps prevent man in the middle attacks. If you use a self-signed cert it breaks part of the security of SSL. While no security is full proof, the harder you can make it for a hacker or scammer the better.

Re:Always.

[I cant believe its n]

Why does Alice have this obsessive need to talk to Bob? :-)

O'Reilly Open Source Convention 2007 - 5 minutes

Re:Always.

[Rayban]

Here's a hint of how it can fail:

Man in the middle intercepts http://wachovia.com/ inserts a JS script in the head of the document that takes each keystroke and posts it to http://evilsite.com./

You log in normally, but evil site now has your credentials.

Note that an evil site could be:

  - a fake Wireless Access Point
  - a malicious ISP employee
  - another site broadcasting fake routing packets
  - another site that has poisoned your DNS cache

etc...

This is why you need form-to-backend HTTPS security.

Re:Always.

[brunascle]

In other words, CA-signed certs arent perfect, so we shouldnt even bother with them? Is that your argument? Ridiculous

no security mechanism is perfect, that doesnt mean we shouldnt try. should we stop using passwords just because they could be brute forced?

a valid CA-signed cert gives you reasonable assurance that the party you're communicating with is who they say they are. a self-signed certificate gives you none whatsoever, and provides no protection whatsoever from anyone able to modify your traffic, which is a large subset of the only group you were trying to protect yourself in the first place: those able to sniff your traffic.

Re:Always.

[Anonymous Coward]

If you decide that you don't trust Verisign, and your bank uses a Verisign cert for their online banking, by extension you don't trust the bank, and should find a new one.

This is so dumb I'm not sure how to reply. By extension, I don't trust my bank? Amazing!

I can't think of an example of a situation where you're forced to trust a particular root CA and have zero choice in the matter.

Intranets.

Re:Always.

[Alpha830RulZ]

Just to simplify things, I have been attacked by a bear. 1968, Glacier National Park, at Trout Lake. Yes, thanks, I survived.

And I do check the addresses I submit to.

Re:Always.

[camperdave]

We're talking different devices then. The ones I'm talking about don't need a card. They each have a unique, factory installed seed.

Re:Always.

[Anonymous Coward]

By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?

Here's one for you...

Let's say that your banks machine got compromised, no changes to its SSL cert, no changes its DNS? How does a CA's website verification help you in this situation?

Nothing...

My point is that you have a faux sense of security if you are relying on VeriSign to tell you that the website is safe. A self signed cert offers you the same level of protection, encrypted transfer only.

Re:Always.

[Anonymous Coward]

http://www.microsoft.com/technet/security/Bulletin/MS01-017.mspx

Re:Always.

[Anonymous Coward]

USBANK used to do it that way. I made sure to bookmark their https site just so I wouldn't use the other one by accident. They changed it now so you can only send your username via http now, the password page is https now.

Re:Always.

[Bandman]

That's a good idea. Of course, if your gym locker gets robbed, then you're hosed, but as long as it still asks for a password you should be alright.

Re:Always.

[sjames]

Even more to the point, the "verification" needed to get a cert can be as little as faxing a confirmation letter with the company letterhead. Given a scanner, 5 minutes, and a letter FROM the company I want to be today, I can easily manage that and so can anyone else. It means nothing.

SSL authentication really just means that one of the companies (any one of them) that was pre-configured in your browser has been convinced (in return for money) to sign a cert. You can trust that authentication to the same degree you trust these companies you may have never heard of and probably haven't done business with.

It's annoying that ssl conflates the separate functions of authentication and privacy. They are related functions mostly because the mathematics behind the two cryptographic functions are the same.

SSL SHOULD be perfectly happy to provide for privacy with or without a cert. A browser should distinguish between the two states but not generate a FUDish collection of click-through dialogs.

SSL implementations should also be configurable for a web of trust. That is, this cert is good because it was issued by a cert that was issued by someone I trust.

I'm sure Verisign would love to replace the web of trust used in PGP/GPG with their signed (and paid for) certs.

On a side note, years ago, when all of this was just being rolled out, I met a verisign rep at a trade show. I asked him how when I request a cert they know I'm not out to commit fraud. He replied "because you have to sign a LEGAL DOCUMENT that says you're not". Yeah, I can just imagine the fraudsters quaking in their boots about signing (but not even notarizing) an actual legal document!!!

Re:Always.

[letxa2000]

Encryption is only a small part of the idea of certificates. The main part is that it gives you, the user, some idea that the web site you are typing your credentials into is who you think it is (eg your bank) and isn't someone else pretending to be your bank.

But that's nonsense. I have been robbed by the SSL certificate companies so that my shopping cart page would not flag any browser warnings. I paid my money and had the certificate the next day. They didn't contact me by phone or snail mail. The most they could've done is verified that the business name I gave them was an actual business--but there's no way they could have verified that I was authorized to request a certificate on behalf of the company.

In short, the whole idea that SSL certificates come anywhere close to proving that a website is who it says it is is nonsense. Only a fool would trust that to be true.

SSL certificates are organized theft and are a racket.

Re:Always.

[dandaman32]

The login page can be un-encrypted as long as the data from the form on that page is encrypted before it is sent over the Internet. Said another way, as long as the form action is "https://mybank.com/etc" there is no problem. The only reason some banks encrypt the login page is to make the customer feel good; it doesn't increase their security one iota.

Not really. You forgot a couple things:

• What if the login page is tampered with during transmission to submit to a different URL?
• How does the user know that the login page wasn't tampered? A paranoid user would probably go in and check the form tag manually to make sure it submits to an https url.
• Therefore, using SSL on the login page is the only way to ensure that your information is going to a trusted site.

Re:Always.

[brunascle]

the user has to verify the cert's signature via an out of band channel

I.E. the CA, using its public key, which the browser already has. To falsify a certificate without the browser telling you, either the CA, the web site, or your machine would have to be compromised. If it's your machine, you couldnt trust your traffic even if you did validate the signature personally. If the web site: it's likely the attacker could get a hold of any information you're trying to hide anyway. If the CA: you, along with millions of other people, are just plain screwed.

Re:Always.

[bonhomme_de_neige]

Part of the security around having the SSL cert verified off site is it helps prevent man in the middle attacks. If you use a self-signed cert it breaks part of the security of SSL. If you're saying that using a self-signed cert is vulnerable to MiTM attacks, while a trusted CA-signed cert is not, that's not true, provided you verify the certificate once (for example, the site could post the fingerprint on many public sites to make it well known), and then tell your browser to trust that certificate for that site.

Then you won't get the certificate warning again, unless the cert changes (as it would in a MiTM attack - it would be self-signed for the same site, but the actual certificate would be different, and your browser would recognise this). The warning then tips you off that something is not as it should be, just as it would if you saw it on a site you expected to have a cert signed by a trusted CA.

Numerous posters above already pointed this out.

Also to reply to vertinox's post (would that be an 'uncle' post?):

A phishing site would have a problem getting a banks cert, but they could even roll their own with something that says "Signed by Verising" and since the person probaly didn't read the address at the top in the first place they most likley wouldn't bother double clicking on the lock on their browser. I think if you tried to get Verisign to sign a cert for "www.commbnak.com.au" (instead of commbank which is a real bank's site), you would not find it easy, because the names are so similar and Verisign would see what you're trying to do. So while it's true some might slip through, I don't think it's as serious a drawback of the system as you imply.

Re:Always.

[Nursie]

"The only thing it does is to assure you that the bank says they are who Verisign says they are. Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty."

Not really. Not "infinite". It simply says you trust verisign to give these things out, and so does your bank. Otherwise they wouldn't have one.

You're right, all the assurance you have is that verisign say that you're talking to who you think you are. And that's enough, provided they don't deliberately mis-sell certificates.

"If I'm the victim of a MITM-attack, why would I even care if Verisign says that the attacker is my bank or not? He's still going to copy the entire encrypted transactions either way."

Umm, if you're the victim then it's already too late. The idea is to prevent MITM attacks from being possible. If the MITM has somehow got hold of a way of -

a) Poisoning your DNS
b) Getting hold of a signed, trusted certificate in the name of your bank.

Then that's what the bank's insurance is for, they've been severely compromised at this point.

Re:Always.

[EmGooser]

I also said that it is not full proof, no security is. The whole point of security now a days is to make it as hard as you can to break it. If you don't want your site hacked or its data comprimised, the 100% full proof solution is to unplug the server and distroy the data itself to prevent an inside job as well. Obviously, this is very extream and does not work for companies.

Re:Always.

[Nursie]

You'd still need to have obtained the private key of whatever org we're talking about, if you want to pretend to be (for instance) hsbc.co.uk, you'd still need to have a certificate that my browser would accept, and in that name.

That's kinda where his objections fall down. Verisign haven't been handing out dodgy certificates in other people's names wholesale. Sure, anyone can get a cert from them, but there is *some* requirement to at least prove ownership of the domain it's for.

Re:Always.

[tonyray]

"using SSL on the login page is the only way to ensure that your information is going to a trusted site."

I see your point, but disagree with your conclusion. Having SSL doesn't prevent the login page from being tampered with (it can still be hacked to change the form action), but it could make it harder for phishing schemes to succeed.

Re:Always.

[naasking]

I.E. the CA, using its public key, which the browser already has.

The CA is one way, but not the best way. You are introducing a whole set of other entities everyone has to trust. Why?

Occam's razor: one must not multiply entities unnecessarily.

To falsify a certificate without the browser telling you, either the CA, the web site, or your machine would have to be compromised.

Who cares about the cert? That's not a major attack vector. Why focus on the attack vectors which aren't a problem in practice? Phishing and spoofing are the low-hanging fruit, and CAs and certs don't help you with this at all. The solution I described above solves all of these problems. All we need is a method of secure introduction to further automate it. Fortunately, that exists too.

Re:Always.

[bonhomme_de_neige]

And when you do something nefarious with your signed code, the police will subpoena the CA for the details of your transaction, get your info from the credit card company, and send a cop to your door. That's fine, because by then the credit card will have been closed and the address on file vacated.

Re:Always.

[slim]

So, who is responsible for a phishing attack using a legitimate cert?

You can say 'the user' all you want, but certs themselves are to blame. They are not a usable authentication tool, despite the claims.

I don't get it.

The browser's doing it's job: it displays the hostname.
The certificate's doing it's job: it validates that the server is run by someone who owns that hostname's private key.

If private data is sent to the wrong hostname, how is this not the user's fault?

Re:Always.

[bonhomme_de_neige]

In most cases, you wouldn't need to compromise the ISP DNS, only the DHCP server the person is using (generally a consumer router). I could see this attack being feasible with a public wireless point or a cybercafe.

Also he is confusing a bunch of different issues in his post in a poor attempt to make a point. Serving up bullshit DNS is a lot easier than getting your brother's friend's sister to give you Google's cert.

But, CA signing protects from a MiTM attack executed by spoofed DNS - you can make my browser go to the wrong IP address for google.com, but you can't present me a trusted certificate.

What GGP is saying is that despite CA signing, he can still trick my browser by getting root on either
(a) my machine, or
(b) google's servers.

Either of these, while not impossible, is a significantly higher bar to jump than just setting up a fake DNS using some ARP poisoning on a public wireless lan or some such. Especially in such a way as to not alert either me or google that our respective systems have been hacked.

If google know it's been leaked, they will straight away contact the CA and have the certificate revoked, at which point browsers will start throwing warnings about it again.

So we've changed the requirements for successful deception from a few scripts (attainable with little subject matter knowledge from a web search) on a linux laptop at Starbucks to hacking google's servers well enough they don't realise they've been hacked. In that case, I think CA signing is doing its job pretty well.

Re:Always.

[Anonymous Coward]

While their login form is on an unencrypted page, when you actually submit the form it posts to a secure page. From the source:

form method="post" action="https://www.melbourneit.com.au/cc/validateformfields"

Here is an example of a bank using a similar setup: http://wachovia.com/ They even have a pop-up note above the login form noting people's concern that it appears insecure.

Re:Always.

[Anonymous Coward]

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.

I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.

It doesn't matter if the page you type the username/password in is encrypted, but if the page you send your username/password to is encrypted.

The login page has already been sent to you, there is no information on there and doesn't need encryption. But when you do send the query with your login-info to them, then it has to be in an encrypted connection.
That is what MelbournIT does, so ti is quite safe to use them.

Re:Always.

[brunascle]

Phishing and spoofing are the low-hanging fruit, and CAs and certs don't help you with this at all.

Of course they help, that's the purpose of CAs and certs. Assuming your machine, the web site, and the CA are not compromised, and your browser didnt tell your the cert was invalid, all you have to do is look at the domain name -- which is what I meant by paying attention. If says paypal.com, then it's really paypal.com. It's unnecessary to validate it any further.

Re:Always.

[Nursie]

No it won't

And do you know why?

Because you are vulnerable to man in the middle on a transparent proxy in your company's network. This is why we have trusted certificate chains - so that we can verify who we're talking to with a piece of knowledge we already hold - the issuing authority's public key.

Re:Always.

[Anonymous Coward]

If you look at the source, the form actually posts to an HTTPS link, so what you enter would be secure.

It is somewhat bad form though, not showing that it's secure (ie having the login on HTTPS), but that example isn't actually doing anything wrong.

Re:Always.

[defaria]

The reason they don't respond is that it's not a problem, rather it is ignorance on your part. What is important is the page your query is sent to and whether or not *that* is https, *not* whether or not the current page you are on is https. The hysteria about security created by the ignorant is amazing and fuels a billion dollar marketplace. Become part of the solution, the educated, instead of spreading FUD!

Re:Always.

[mishehu]

Maybe I am incorrect about this, but I thought that the key itself is what provided the encryption, and that the certificate provided a means to verify the key. This entails having "somebody else" vouch for you, in this case it would be a CA. If I'm incorrect, please correct me.

Re:Always.

[FooAtWFU]

Haven't seen a bank do it? Try Wachovia. A pretty big bank, as such things go, too.

Re:Always.

[Anonymous Coward]

I might be mistaken, but it appears that the log-in process does use encryption even though the initial form is on an unencrypted page. The form's action attribute (observed using Firebug) is set to https://www.melbourneit.com.au/cc/validateformfields, so the submission appears to be encrypted.

Re:Always.

[OnlineAlias]

And yet they still have an unencrypted login on their home page. Submitting to an encrypted URL from an unencrypted URL is practically a phish in itself. Most banks do this, and I cringe every time I see it. It begs for a phish attacks, does a disservice to customers, and promotes bad computing habits. But hey, it doesn't really cost the bank anything if your username and password gets whacked.

 

Re:Always.

[Sir_Real]

Verny? Thatyou?

Anyhow.

Your point is well taken, but doesn't state the real issue. This has NOTHING to do with being more secure and EVERYTHING to do with "accountability." Which is lame.

Re:Always.

[Anonymous Coward]

And those certificates were almost immediately revoked. Firefox 3 (by default) and IE7 (optionally) check OCSP for certificate validity and will not allow those certificates to be trusted.

If someone were impersonating a Microsoft employee using a self-signed cert and you chose to trust that cert when issued then you'd still trust that cert now.

Re:Always.

[naasking]

Is the information presented to the user in a way that is meanginful to them, such that they can then verify the legitimacy of the site?

No. I described this elsewhere together with a real solution.

Re:Always.

[naasking]

Responded to the wrong post. Let's try that again:

If private data is sent to the wrong hostname, how is this not the user's fault?

Is the information presented to the user in a way that is meanginful to them, such that they can then verify the legitimacy of the site?

No, a user requires significant technical knowledge to make this judgment. The system is flawed. I described this elsewhere together with a real solution.

Re:Always.

[naasking]

Of course they help, that's the purpose of CAs and certs.

No, they really don't.

Assuming your machine, the web site, and the CA are not compromised

Which is still one more point of failure than the system I desribed.

all you have to do is look at the domain name -- which is what I meant by paying attention.

I know exactly what you meant. And yet, with Unicode URLs becoming standardized, we now have multiple glyphs that look exactly the same but are really different characters. How do you protect yourself then?

Furthermore, your stronger technical background is blinding you to the fact that the information presented in a URL, a cert, and so on, is not as clear to others as it is to you. You're also conventiently forgetting all the things you can't do, like follow links in e-mails purporting to be from your bank. The petname tool approach solves all of these problems.

It's unnecessary to validate it any further.

There is no "further validation". The petname toolbar requires less validation than a CA-based system.

Re:Always.

[hab136]

no no no, really you don't understand. Since the login page is not encrypted, it may have been changed during transfer to your browser. You'll be sending your user credentials to the evil MITM.

Any attacker that can modify your site can change your site to point to a non-encrypted login page, or an encrypted page off-site that the attacker controls. Making the login page encrypted (but not the whole site) isn't much more secure, since the attacker can change the link to the login page to go elsewhere. If the user has bookmarked the correct login page, the attacker can throw them an error (or just close the connection) and the user will most likely start over at the site's home page, thinking that the site has moved their login page.

One can make an argument that the entire site needs to be encrypted if any part is (PayPal does this). Encryption slows things down and requires more hardware though, so it's a cost vs. risk assessment.

Re:Always.

[EvanED]

IF you can spoof mybank.com.au's DNS then you can apply for a certificate to that domain yourself... Most certificate authorities just send you an email to confirm, and if you control the DNS you can control the MX records to ensure you receive that mail.

Not really. If I can spoof your DNS server to you, I can redirect your requests to me and do a man-in-the-middle attack on you (modulo encryption). If I set up a wifi hotspot, I can run my own DNS server that redirects stuff from you to me.

If I want to spoof someone so that I get the email that Verisign sends out, I have to spoof *Verisign's* DNS. And really, if I were Verisign, I would try a number of different DNS servers to make sure they all agree, so I would have to spoof all of them. (At least assuming this is possible; I don't know enough about IP to know if DNS entries can legitimately vary like that.)

Re:Always.

[PuckstopperGA]

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.

I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.

Actually the site you mentioned DOES process your login through SSL. If you look at the form action, it is sent to a HTTPS address. Now looking at the web page, the blank form is sent unencrypted, but the login is handled over SSL. That's the way some banks operate to avoid the sluggish load times with HTTPS compared to regular HTTP.

Re:Always.

[EvanED]

I don't think he's talking about subversion. He's talking about the fact that anyone with $900 can buy a cert from verisign regardless of their evil intentions.

But they can't buy one for my bank, or for Amazon, or for Paypal.

His point was that since any malware site or someone who just intends to steal your credit card on a legit looking site could in theory buy a legal cert, that rolling your own is just as trust worthy.

But it isn't. Roll-your-own SSL cert doesn't provide protection against man-in-the-middle attacks (unless you have previously visited the site and stored the self-signed cert); a Verisign-signed cert does (to the extent you trust Verisign).

Just because self-signed certs don't always help with phishing doesn't mean there aren't other threats they DO help against.

Re:Always.

[Anonymous Coward]

If you *knew* that "Veri"sign doesn't actually do much in the way of "Verifying" (except that you have a valid credit card number to pay them with) then why were you arguing with him about it?

Self-signed certificates provide the same level of security and authenticity provided you *Perminatently* accept the public key AND you also know you're getting the right public key the first time. If and when it changes you know something is goofy.

Oh, and those "melbourneit" guys don't *SUBMIT* the form to an unsecured page. It doesn't matter if the input boxes are on an "http" site if they submit to an SSL site. Lots of sites do this.

Re:Always.

[Ifni]

http://www.oxid.it/cain.html

This makes MITM so easy anyone can do it. They don't even have to be your upstream provider - they just have to be sharing the same wireless connection, or be on the same wired network. No, a switch won't help, because it can use ARP poisoning to become your gateway to the Internet.

So yes, eliminating just one attack vector does improve security significantly if it is an easy to exploit vector.

As a point of interest, I was once in a CEH (Certified Ethical Hacker) class for work and fired this baby up. An entire classroom full of "security experts" of various levels of skill. Even though a few noticed that the CA signed certs for their favorite sites were now popping up a browser warning ("hey, why is this popping up?"), to a one, they all accepted the new cert anyway and checked their email/bank account/Paypal.

So, while it's good to eliminate one potential avenue of exploit, the larger avenue remains one of proper education, even for "experts".

Re:Always.

[EvanED]

while a trusted CA-signed cert is not, that's not true, provided you verify the certificate once (for example, the site could post the fingerprint on many public sites to make it well known), and then tell your browser to trust that certificate for that site

It helps, but it's still far from a particularly good solution. Assuming your browser will store things indefinitely, the window where you're vulnerable to a MITM is substantially shortened -- they have to be there for the initial visit.

But if they are -- bye-bye security. Are you really going to go around and look at those many public sites to verify the fingerprint? Even I wouldn't do that unless there was no alternative. I'd find some other place to do what I wanted before that. If the security matters enough I care if other people are reading what I'm saying (as a matter of practice and not an "encrypt everything" ideology I'm somewhat partial to) and the target can't be bothered to get a "real" cert, I'm probably going elsewhere.

You can only say that CA-signed certs don't help against MITM if, at the point you are receiving the self-signed certs, you trust your network as much or more than you trust the CA. Frankly, for me, that would never be the case right now.

Re:Always.

[EvanED]

As many others have said, do you verify the HTML of the page you load when you load an unencrypted login page?

If you don't, how do you know that a MITM didn't modify it to redirect that form input? How do you know a MITM didn't modify it to insert javascript to forward everything you enter in that form to him?

An unencrypted login page is only as secure as an encrypted login page if you open view source and look.

If my bank did that, I would only use the web interface in an absolute emergency. And then I would get a different bank.

Re:Always.

[sjames]

Something like: no key = not encrypted or authenticated. Plain key = encrypted, self-signed cert, silver key = cert signed by a CA in the browser's list. Gold key = key I have selected as proven or signed by a CA I have configured as personally trusted.

Re:Always.

[Anonymous Coward]

It's a good example of the fact that it has up until now been "Good Enough (c)" identification. But this fact does not disprove the correctness of the original post - identification cannot be 'proven' with this method. That's that.

Re:Always.

[EvanED]

However: If Alice talks to a legitimate merchant, and no one has hacked anything, then the conversation between her and the other end is very difficult to break into, moreso than her computer, I might add. Which is the same advantage you would have had with self-signed certificates. The ONLY time you're safe is when you've not been hacked. To say that because ONE hack has been deterred -- the MITM attack -- the user should feel safe... I'm not buying it.

Okay fine. What would you suggest?

A CA-provided cert is better than a self-signed cert, period. How much better depends on your trust of the CA. I would tend to say quite a bit better.

Sure, there are other attack vectors. But let's take your argument the other way. SSL in the first place. Why bother with it? After all, if my computer is rooted, or if the legitimate merchant's computer has been rooted, then the information has already been lost and encryption doesn't help. To say that one hack has been deterred -- the evesdropping attack -- the user should feel safe... I'm not buying it. How does that sound?

(1) Plain HTTP gets you no security.
(2) SSL with self-signed certs gets you protection against evesdropping. If you can establish the certificate out-of-band, it gets you protection against MITM. If you can save the cert, it substantially narrows the band where you are vulnerable to MITM, to when you first get the cert.
(3) SSL with CA-signed certs gets you protection against MITM at all times, to the extent you trust the CA. (Note that all of the options for additional verification present in (2) are also present here.)

(3) is strictly better than (2) which is strictly better than (1). What are the relative weights? The jump from (1) to (2) is substantially more than the jump (2) to (3) I would say. But you still get help going from (2) to (3).

Re:Always.

[Cerebus]

For keys issued in software form; yes.

For keys generated on secure crypto processors, you're wrong.

Re:Always.

[locofungus]

It only guarantees that the domain of the site you've connected to matches the domain in your browser bar.

So I set up a company usesave. It doesn't really matter what the company was going to do.

I then get a cert from verisign for my usesave company.

I then setup www.usesave.co.uk, and maybe even phish people with "you must check your details" and wait for people to typo www.icesave.co.uk or click on links in the phishing email.

Of course, hopefully, the site will get shut down quickly, but it's unlikely to be quickly enough not to catch some people out. The steps above might have cost me a few hundred pounds. I can set it all up and then "disappear" before actually triggering the phish. During the setup time my website is displaying a "How to save the environment by reusing the stuff you throw away: Coming soon"

But instead, icesave could have had their own root cert. And despite being an online bank, you do still have some paperwork from them which could have included the fingerprint of their root cert.

Now I can explicitly allow icesave's root cert and it doesn't matter if someone sets up usesave. If I typo it I won't recognise their root cert so I'll be alerted to the typo.

Of course, browsers don't make this at all easy to do. And, of course, icesave could still give their fingerprint on their paperwork (they don't).

For less critical transactions it's less important. If I'm just buying something online then the verisign checks are probably fine. I'm not likely to have any good way of verifying the companies cert. But there's no loss of security by still having a self signed cert - it's actually impossible for me to tell if the people I'm talking to are crooks - and verisign confirming that yes, I've really connected to the crooks and the good guys haven't intercepted my connection really doesn't help me.

What certs really give is the potential to confirm that the person you're talking to today is the same as the person you were talking to yesterday. But that's not the way they're used at all.

Tim.

Re:Always.

[meatspray]

Bluecoat, the maker of my companies choice web-filtering software puts a transparent proxy in between the users and the web. The boxes are able to man-in-the-middle the web sites cert and create a new locally signed certs. (authorized via GPO)

if you inspect the cert it initially looks fine, until you peek under the hood and see the details.

They claim to be able to do the same with ssh... I'm glad ssh warns you of such travesties.

It's certainly not taking over a banks website, but a real world example about how insecure SSL can be in the right environment.

Re:Always.

[Anonymous Coward]

As long as the user never enters confidential information into unencrypted pages, everything's fine (as far as the user can help it). Providing unsecured login forms on the real site trains people to violate that principle and creates the attack vector that you describe.

Re:Always.

[Anonymous Coward]

Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots. if you actually looked at the html source for their login page, you'd see that the form is actually submitting across a secure (https) connection!

Re:Always.

[Anonymous Coward]

Well whomever gives their private keys out deserves to be punished. Of course SSL provides verification on who is on the other end, but it's still based on trust. You trust that Verisign and the key owner don't give the private information out to others. Anyone using your private key is acting as you. It's similar to the real world.. A bouncer at a bar trusts the DMV to only hand out driver's licenses to people who are who they say they are. The bouncer does a quick sanity check and if it looks like you, then it must be you. But let's say you give your driver's license to someone underage that looks like you. Then they use your ID at that same bar and they could get passed the bouncer and drink. Well, if they get busted, you are in trouble just as much as your friend is for using your ID because they were acting as you and you gave them your ID when you shouldn't have. That friend was acting as you. Now the self signed certificate can be similar to using a fake ID (McLovin' style). The bouncer might be able to notice some suspicious things about your ID (like the domain name being wrong) and should deny you. If they knowingly give you access simply because you have a driver's license that kinda looks real, but doesn't have the holograms/security markers on it then the bar will be responsible for serving to a minor.

Re:Always.

[FrangoAssado]

While that's true, it also misses an important point: the guarantee that you're talking to the same person certificate was signed to by the CA.

If you accept a self-signed certificate, you can never be sure who you're talking to -- maybe someone intercepted the communication and generated a different self-signed certificate.

Re:Always.

[rbrewer123]

Wachovia is training its users to input their credentials on insecure pages. The users have no way of knowing if the page is submitting their credentials to Wachovia's site or somewhere else. The front page could be easily spoofed. Therefore, I don't believe you when you say they are quite serious about their IT security. I think they are more serious about saving some CPU power on their servers by not encrypting the front page. If etrade, paypal, and other security-conscious sites can encrypt their front page, so can Wachovia.

Re:Always.

[operagost]

A cert can be subverted through the usual methods: carelessness, and social engineering. An exported cert could be left hanging around on a file share or CD-ROM, or the password could be revealed in a plaintext email.

Re:Always.

[brunascle]

I'm Evel - and I have hacked Alice's computer

Stop right there. You're taking it as a given you've already gotten into her computer. If you have, absolutely nothing on her computer is secure.

SSL is not a magic wand that can protect everything. It has one specific duty, and it does it very well. The fact that it doesnt work on a system that has been compromised is completely irrelevant. The same is true with every security mechanism. That does not mean you shouldnt use it.

Re:Always.

[osu-neko]

You really should read and understand more about this before spouting off like some sort of authority.

Encryption by itself is not very useful, as it only operates at the network layer. So some nefarious network user or ISP admin will be unable to read your communications. Big freaking deal.

You really should read and understand more about this before spouting off like some sort of authority.

Among other things, you should understand that different people's security needs differ, depending on the situation. Often that's exactly what is needed, and nothing more is required or useful. It frequently does nothing but cause harm to complicate the issue by throwing in SSL certs meant to solve problems that are complete non-issues in many contexts.

Re:Always.

[wkcole]

Can you cite any examples of a case where a certificate has been subverted in this way?

Well, it was never made completely clear how Verisign screwed up in issuing two "Microsoft" certs for code signing (still X.509 certs) to the Wrong People back in 2001, but that is the canonical example of "legit" certs landing in the wrong hands and it helped spread better cert checking in browsers.

And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?

I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.

I don't think the poster you are responding to has an alternative solution. There isn't one. That does not mean that X.509 certs as they stand are really all that good. People turn off or weaken CRL checking and OCSP, CA's are selling server certs with effectively no identity checking, and it is in the business interest of all commercial CA's to have a market where there are a price differentiated range from cheap meaningless certs that say nothing valuable about identity to very expensive certs that can be argued to mean more. At that high end, the "EV" certs really are a bit more meaningful, but they are still open to compromise. The way revocation works and the way people set up their systems to use it, a working compromise could survive for days between the discovery of the compromise and the last time any browser is likely to use cached trust based on earlier checking for revocation.

Re:Always.

[KutuluWare]

I've always liked the way Bank of America handles logins, though I'd like it more if the whole site was encrypted.

On their unencrypted home page, all you get to enter is your user name or ID. Then you submit to a page that pulls back what they call a "Site Key" -- in this case it's a photograph and associated phrase that you picked when you sign up. On that (encrypted) page you enter your password.

This means that, by the time you've entered your password, you know that:

* The site taking your password has a valid security certificate
* The site taking your password claims to know who you are based on your user ID.
* The site taking your password knows you told them to show you a picture of a full course breakfast.
* The site taking your password knows what funny words associate in your brain with bacon and eggs.

From a consumer perspective, this makes me pretty confident that I'm really logged into Bank of America; it opens them up to the brute force attack looking up valid user names but I'll let them deal with that.

Re:Always.

[Bill, Shooter of Bul]

Good Point. Its nice to see a bank, and its former employees take security seriously and understand all of the potential risks.

Excuse me, now there is some business to which I must attend.

{transfers all accounts OUT of wachovia}

Re:Always.

[KutuluWare]

It prevents the easier types of tampering -- man in the middle. That is, the only way to silently tamper with an encrypted page is to do so on the server pre-encryption. Without encryption, anyone that controls any part of the data stream can tamper with the data before you get it and you'd never know unless they screwed up.

Re:Always.

[osu-neko]

The same argument can be said about any kind of identification method. Any form of ID can be forged, the documents presented to get one can be forged, so I don't really see the point in singling out SSL.

The point is, SSL encryption is often useful, indeed often more useful, and CA authentication. You shouldn't need a certificate just to use an encrypted channel. The current scheme weakens network security overall, because it discourages the use of encryption more than it encourages the use of authentication. Pointing out how poor the authentication really is is just highlighting the irony.

Re:Always.

[osu-neko]

So, the conclusion you're drawn from the fact that a self-signed cert doesn't solve every possible problem is that it's no better than unencrypted HTTP?

You either have an overinflated estimation of the power of signed certs, or you're suffering from an incredibly big double-standard.

Neither solution solves all problems. But what the GP said holds -- a self-signed cert still beats unencrypted HTTP by quite a lot. If you have to whip out a transparent proxy to prove why a solution won't work, when that solution solves the kind of spying any idiot with a network jack can do, you utterly fail at basic security. It's never about preventing all possible attacks -- that's impossible. It's always about balancing realistic security concerns with realistic usability concerns.

I can't tell you how many times I've seen security weakened by people who can't balance these properly and enforce standards too extreme while discarding better solutions because they aren't perfect.

Re:Always.

[Rene S. Hollan]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

Well, technically it is possible to use them for endpoint authentication without encryption (which might be useful on a physically secure point to point link where one can't tell if the endoint has been compromised, and endpoint posession of private keys is transient, though why not encrypt as well, then?) but browsers are not configured to work that way.

But, yes, endpoint verification is only as good as the trust you place in whoever signed the certificate the endpoint presents.

In a closed community, with a secure means of distributing certificates, self-signed certs are fine. In fact, they are used to set up VPN links all the time.

Well-known CAs serve the purpose of vouching for the identities third parties present -- they are rather like government issued drivers licenses, or other photo ID. Bars use them all the time for age verification. Of course, the checking that most CAs do, compared to drivers' licensing departments is laughable, but that's a completely different issue from the potential usefulness of a signed X.509 cert.

The whole point of certificate authorities is scalability: one does not have to verify every single certificate individually -- one need only have trust in the (few) authorities that sign them. Even if one accepts self-signed certs from one's correspondent, it would make far more sense for the correspondent to generate one, and use it to sign the certificates used by all their servers, instead of having a self-signed cert per server.

PGP decentralizes the notion of a CA, but makes establishing individual trust webs more cumbersome. Some would argue this is a good thing. But, ultimately, who's signature you trust on a certificate is up to you, and no, it should not be blind.

As for vouching for the repeatability of reaching a given endpoint, even without CA signatures, this is only true when the endpoint's private key has not been compromised. So, you have to trust the care your correspondent places in their servers. This is also an argument for accepting self-signed certs as siging certs from known conterparties, but not as endpoint identification-serving certs: if the endpoint is compromised, but the CA cert isn't (managed by the same entity), CRLs and OCSP servers can still be trusted to say "certificate X has been compromised". If the signing cert is compromised, ALL certs signed by it can no longer be trusted, nor any related CRLs or OCSP servers.

Always kmow where your signing cert is.

Re:Always.

[Anonymous Coward]

Exactly. SSL Certificates alone cannot tell you who you are talking to.

There *should* be a method wherein people can generate self signed certificates, and then have those certificates signed by *several* authorities.

This way the browser can contain a list of trusted authorities, and a minimum number of signatures required from that list. Requiring the signature of more than one authority would mean the 'identity' portion the SSL CA tries to solve wouldn't rest in the hand of one organization, but would require independent verification from several.

Re:Always.

[Anonymous Coward]

How many more idiots are going to use this opportunity for an outing as security noobs? The login page can already be a rogue page, for example when the login page is visited over a hostile wireless hotspot. It can send the information offsite as well as to the right target. The only way to detect such an attack is to inspect the full source of the unencrypted login page and every script it loads, which I'm sure you do every time, right?

Re:Always.

[Silicon Avatar]

um, if this page is already under attack, it doesn't matter WHAT you do.

Re:Always.

[h4ck7h3p14n37]

Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.

While not exactly the same situation, there was this story about Verisign issuing certificates that allowed code to be signed, "Microsoft Corporation", to someone not affiliated with Microsoft. I don't recall exactly how long it took Verisign to realize the mistake.

As far as self-signed certificates go, there's really no issue using them so long as you understand how they work. They're pretty common on private networks, but it's poor form to use them for servers on the Internet.

Re:Always.

[EkriirkE]

Not a problem no, but I can see if they become common place in the general arena it would cause that kind of desensitization. People are stupid, they don't realize they have a problem until all the adware/spyware that they've accumulated adds so many toolbars they can no longer see the page they want, or when their OS starts crashing "too much". A lot of these get installed by the user's own clicks because a phony alert came up telling them "ALERT! You're not protected! click here!", etc

Re:Always.

[Digital_Quartz]

Umm... no. A certificate proves who is on the other end, because whoever is on the other end has the private key associated with the certificate, otherwise they wouldn't be able to negotiate the SSL link.

The only way for someone else to be in control of the certificate is to gain access to that secret key, which implies a great deal of carelessness on behalf of the certificate owner, since no one (not even the CA) should have the secret key.

The value a CA adds is that the CA certs are well known. The CA verifies that the certificate in question belongs to the site or person in the certificate's subject, and then signs the cert with the CA's private key. Since I have a copy of the CA's certificate ahead of time, I can use it to verify the signature, which means I know the cert was signed by the CA, which means I know the cert belongs to the person who claims to own it (assuming I trust the CA).

Re:Always.

[Sancho]

Encryption is nice, but the more important value in ssl certs is that they verify who it is that you're talking to. Only the root post pointed out that this is something you don't get with SSL as it is currently implemented.

Re:Always.

[Anonymous Coward]

SSL certificates encrypt conversations. Certificate authorities prey on fear and install a completely false sense of security. Browser authors are in cahoots with the cert authorities. Those are the three key truths about SSL that a truly savvy consumer understands.

Sorry - that's bullshit. SSL certificates do not encrypt conversations. SSL certificates are used to authenticate the endpoints of the conversation before an ephemeral, shared, symmetric key is generated by the endpoints - usually using Diffie Hellman.

Re:Always.

[Lord Ender]

You think PKIs are worthless? You must be a sales goon for PGP. Well you can take your web of trust and shove it up your 65537.

Commercial PKIs verify that, at the very least, there is a money trail associated with each certificate you interact with. And there are newer levels of certificate signing coming out which verify that some certificates have been extensively audited to ensure that they were issued to the legitimate business owners, and that those owners have some level of protection of the certificate itself.

That is a real, valuable advantage compared to self-signed certs.

Re:Always.

[Anonymous Coward]

It has been explained a dozen times now. What is it that you don't understand? Anybody between you and the bank can trivially change unencrypted pages. Open wireless hotspots come to mind. There are attacks where the bad guy doesn't have to sit between you and the bank to change unencrypted pages. All these attacks can be averted with proper use of SSL. Unencrypted login pages are not proper use of SSL, even when the form data is then (normally) sent via an SSL connection. Jesus, folks, you have eyes. READ.

Re:Always.

[mrtctc]

>>SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate. Exactly.. We use Self Signed Certs for a lot of applications simply to provide encryption. You can buy a real cert in exactly 90 seconds (or thereabouts) from Rapil SSL or some other company like that. They do no checking whatsoever and only require that the cert is sent to an email address at the domain that is applying for the cert. SSL Only provides encryption, and I wouldn't personally trust them for identification.

Re:Always.

[Sancho]

It's not just an e-mail address on the domain--it's a specific e-mail address on the domain. All of the CAs I've dealt with sent authorization information to the technical contact for the domain. Could it have been compromised? Sure. Is it likely? It's less likely than you make it out to be.

There are lots of trust problems on the Internet, and I'm sure that there's room for improvement, but let's be realistic here. Self-signed certs are more spoofable than CA-issued certs if even minimal information is checked when issuing the latter. If the user doesn't want to trust the CA-issued cert, they can disable the root cert in the browser.

Re:Always.

[ady1]

>>The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.

You are confused, my friend. An SSL certificate, like an earlier poster already pointed out, is only there to encrypt the traffic. It doesn't ensure identity and is not meant to do so regardless of what VERISIGN signup page tell you.
THere is only one way to ensure that you are at the site you intend to: LOOK AT THE ADDRESS BAR. Its why its there for.

Off the topic, IE8 has a neat feature in which it highlights the domain part of the URI. Makes it easier for you to figure out which site you are on without significant mental effort.

Re:Always.

[Anonymous Coward]

You're an idiot. Not because you didn't know why login forms on unsecured pages are a problem, but because YOU DIDN'T READ to find out about it.

If I ever need an example of the decline of Slashdot, I'll point to this thread. It's remarkable how many people come here to reveal their naivety even though the problem with their argument has been pointed out more than a dozen times in the same thread.

Re:Always.

[theresonly1m]

what on earth are you on about? Trusted CA certificates do provide very strong authentication, especially through EV certificates due to the stringent vetting. Just look at the browser vendors and the warning message displayed by them when a self signed certificate, expired or name mis-match certificate is used. Are you claiming that all browser vendors and CA's are in league with each other to scam the public? If you understood the actual vetting that a CA does then I am sure that you would endorse SSL certificates instead of rubbish them.

Re:Always.

[Anonymous Coward]

From a consumer perspective, this makes me pretty confident that I'm really logged into Bank of America

From a hackers perspective, this makes it pretty easy to harvest legitimate usernames to use to try to find weak passwords. No doubt they have protections in place to limit the number of incorrect attempts by a single IP or block at entering a username, but a somewhat sophisticated botnet could probably get around that.

There's a reason why the standard practice is to validate both username and password together and not say which of the two was wrong.

Re:Always.

[Kattspya]

Sweden, Skandinaviska Enskilda Banken more known as SEB.

Re:Always.

[vimh42]

It is the CA's who provide a false sense of security, not a website using an unsigned certificate.

Re:Always.

[jamesh]

Let's say that your banks machine got compromised, no changes to its SSL cert, no changes its DNS? How does a CA's website verification help you in this situation?

It doesn't help you, but it's not designed to. It's designed to give you some confidence that it's actually the banks machine you are talking to.

If the banks machine is compromised then they've got bigger problems anyway. I don't think you quite understand the problem that ssl is trying to solve.

Re:Always.

[jamesh]

The login page has already been sent to you, there is no information on there and doesn't need encryption. But when you do send the query with your login-info to them, then it has to be in an encrypted connection.
That is what MelbournIT does, so ti is quite safe to use them.

Have you understood nothing?

Without the login page being https I cannot tell if I am really talking to MelbourneIT or if i'm really talking to a 'man in the middle'.

Re:Always.

[jamesh]

It is somewhat bad form though, not showing that it's secure (ie having the login on HTTPS), but that example isn't actually doing anything wrong.

If you understood that the reasons for https extend beyond encryption then you would understand why it is wrong for them to do that. Please read the other posts about 'man in the middle' attacks.

Re:Always.

[Anonymous Coward]

1) SSL certificates do get issued to phishing sites

I figured that would probably happen, but i'd never actually seen it. I don't make a habit of deliberately visiting phishing sites though.

2) Some banks have login forms on un-encrypted pages

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.

I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.

The Melbourne IT login form does submit to a secure URL, so login details are never passed unsecurely.

Re:Always.

[GWBasic]

Simply sticking a box between a client victim and server victim is not enough, you have to actively compromise one of the four groups above in order to spy on secured traffic.

What about a box that can spoof Windows Update?

Re:Always.

[IntlHarvester]

> But, CA signing protects from a MiTM attack executed by spoofed DNS

Yup, that's the point I made a poor attempt to make.

Re:Always.

[Anonymous Coward]

Hitler

Re:Always.

[Free the Cowards]

Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty. It requires no such thing. I do not have infinite trust in Verisign and their compatriots. On the other hand I trust them vastly more than I trust my ISP not to fall victim to a DNS poisoning attack, and thus I am vastly more secure this way.

Re:Always.

[IntlHarvester]

Netscape used to show a "broken lock" icon whenever browsing an unencrypted sites.

The problem was nobody knew what the icon meant and it reduced the visibility of encrypted sites.

Re:Always.

[Ernesto Alvarez]

I sometimes wonder why the designers of SSL mandated a certificate at the server end.

They did not.

From section A.5, rfc 4643:

      The following cipher suites are used for completely anonymous
      Diffie-Hellman communications in which neither party is
      authenticated. Note that this mode is vulnerable to man-in-the-
      middle attacks and is therefore deprecated.

        CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
        CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
        CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };

There is one advantage when using a certificate, though. You can accept it and keep a copy, thus preventing an impostor from impersonating the site in the future (assuming you got the right cert the first time), just like ssh keys.

Re:Always.

[cbhacking]

Thank you for pointing this out so clearly. It's sad to see sites that claim that since they actually send the credentials securely, they don't need to encrypt the whole login page. They totally don't get that if I have enough access to read their packets on the way to the server (which is what encrypting the credentials is supposed to prevent), I probably have enough access to inject or modify the login page (which, without encryption, is unpreventable and difficult to detect).

Re:Always.

[cbhacking]

Firefox 3's default is only to check a certificate if it specifies an OCSP server (rather than to check a built-in server), and to allow the certificate (rather than treat it as invalid) if the server can't be reached. X.509 certs aren't my specialty, but it seems likely this behavior could be subverted.

Re:Always.

[cbhacking]

Sure, if you manage root access on a server (it happens, sure, but rarely enough that the risk of it occurring doesn't utterly invalidate security measures which assume it hasn't) you could probably steal the server's private key - I wouldn't know where to look but I'm sure its possible. Of course, this means a self-signed cert is equally as hosed as a CA-signed one.

However, IIRC (and I might not), the domain for which the cert is valid is part of the thumbprint, and the thumbprint is part of what is checked by your browser (through the CA). In that case, even a poisoned DNS pointing paypal.com to your computer isn't going to help, unless you somehow secured a cert issued to paypal.com (not impossible, but vastly harder than getting a CA-signed cert normally). On the other hand, you could use a self-signed cert for paypal.com, and in your world the user would very likely just accept it.

DNS poisoning is just one form of MITM attack - the easiest would be to simply set up a public access point that routes all SSL traffic through a program which modifies its own self-signed cert to look like the valid one. (as a class project, I wrote such a program last fall). In your world, it would be just another self-signed cert, and nobody would notice or care. In this world, it produces a big scary warning. Trust me - this type of MITM attack is very easy, especially as compared to rooting a webserver. What's more, if your attack on the server is detected, the owners would probably revoke their old certificate and get a new one (sure, it costs them money, but not as much money as it would cost them to let you run around with their private key). By comparison, a server being attacked through a MITM doesn't even know it's under attack - all it sees is another client connecting just like normal.

In conclusion, MITM attacks are definitely enough of a danger to warrant certificate signing by trusted parties (i.e. CAs). As for your argument about rooting the server, security is all about defense in depth. You don't throw away a valid protective measure against one class of attacks just because a different class allows the attacker to bypass the first one.

Re:Always.

[Anonymous Coward]

Washington Mutual does it too. Even worse, if I explicitly type https://www.wamu.com/ in my address bar, they redirect me to an insecure page with a login box:
http://www.wamu.com/personal/default.asp

WTF?

No way am I typing my password into a http://... page. At least there's a link to a https hosted version of the login form, but it's still a totally lame setup.

Re:Always.

[iabervon]

Call up your bank and get their certificate fingerprint. Compare it against the fingerprint of the certificate you get from the site. If they match, either the site is safe, or your bank is hopeless. Just because somebody's managed to convince a CA to issue a cert to them for www.mybank.com.su and their site looks just like your bank's site doesn't mean it's actually your bank. For all you know, you've made a typo and you're giving your info to some Russian cybercriminal. Or, for that matter, somebody could have subverted your DNS to redirect you from the right domain to a similar looking domain for which they got a CA-signed certificate. CA's only check (if they check anything) that the person is who they say they are; they can't check that the person is who you'll think they are, because they don't know how you could be misled. That's why the only way to be really safe is to verify the certificate by means of the relationship you have with the owner.

Re:Always.

[bpkiwi]

The National Bank in New Zealand

Re:Always.

[jamesh]

So in your hypothetical exploit, the following sequence of events would happen:

1. I sit down in an internet cafe with my laptop and connect via wireless to the internet using the provided wireless network.
2. The wireless network is being run by badguys, so when I type 'http://www.mybank.com.au', it does a redirection to 'www.mybank.com.su' (which I don't notice) and click the 'internet banking' link.
3. The internet banking link sends me to https://www.mybank.com.su/ which has a valid ssl cert for it (domain validated)
4. I still don't notice and enter my login details.
5. My login details are captured by the bad guys and the site reports 'Due to maintenance this site is unavailable. Please try again later'.
6. I think nothing of it and don't notice anything out of the ordinary until funds start disappearing from my account.

That would probably fool enough people to be worthwhile.

Things that would break it are:
1. Me paying attention to the URL (this wouldn't necessarily help if they did something tricky like have the fake .au site load the .su site in an IFRAME, although maybe my browser might pick this up)
2. Me verifying the certificate. The bad guys might be able to get a domain validated cert easy enough (www.mybank.com.su), which could easily be missed, but not a company name validated cert (My Bank Of Australia Pty Ltd), which aren't given out nearly so freely. They browser treats them the same way though.
3. Me verifying the fingerprint, as you suggested. Does the fingerprint change when the cert expires and gets renewed?
4. Me using a second authentication factor (which I do), and the bad guys not using my login details immediately (the second authentication factor is a token which presents a different 6 digit number every 90 seconds).

This would make a really cool security exercise, to reproduce the above scenario in a controlled environment and see how it pans out.

I guess at the end of the day, you have to make sure that you are not the 'low hanging fruit' that the bad guys will pick first. As long as there is someone easier to fool than you, you are probably safe.

Re:Always.

[I cant believe its n]

Your argument goes like this: Name one person who has been attacked by a bear. If you cant, then nobody has ever been attacked by a bear. I understand that it may be a rare and for the average person an unlikely event, but none the less, certificates can become compromised one way or another.[You seemed to have dropped this line]

No. It doesn't. There is a difference between 'could possibly happen in theory', and 'has happened before'. Bear attacks have happened and there are plenty of examples of such attacks, but if there are no examples of something having happened then it must at least be unlikely, and perhaps has never happened before, in which case it's just speculation.

I stand corrected, there have been numerous reports on bear attacks. On the subject we where really discussing, do you think it is impossible to subvert the certificate system if you have the resources of a nation behind you (think NSA)? (And no, I never mentioned communicating with my bank, other people did that).

Re:Always.

[I cant believe its n]

Yes, thanks, I survived.

Prove it :-)
... and thanks btw for making me loose my entire bear attack defense / attack.

---

How do we know you're not Mel Torme?

Re:Always.

[Anonymous Coward]

I've not seen a bank do it, but these guys do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots. did you never try to stick an 's' after the http!

Re:Always.

[jamesh]

On the subject we where really discussing, do you think it is impossible to subvert the certificate system if you have the resources of a nation behind you (think NSA)? (And no, I never mentioned communicating with my bank, other people did that).

If I gave the impression that I thought it was totally impossible then I apologize. For day to day working i'm happy to trust Verisign to protect the secrets that I want protected.

Given all the other possible avenues available to an organisation like the NSA, I'd be surprised if they chose that route though. And if the 'secrets' you are exchanging are important enough that the NSA might be interested in them then I agree with you that trusting verisign might not be the best thing to be doing.

For that reason, I don't really see that there is a problem.

But my standard answer to that sort of thing is that it doesn't matter how much technology you throw at keeping things secret, if 'they' want your secrets bad enough they'll put a gun to the kneecaps of your child/wife/husband/mother and demand that you give them up. That would work for me.

Re:Always.

[duffbeer703]

I cannot think of an application where having some assurance that you are connecting to whom you think you connecting to are one and the same. For experimental or extremely low-value transactions like avoiding your work proxy, you can self-sign.

In the case of P2P sites where you're illegally distributing movies, music, software or pron, you're basically doing the equivalent of leaving fingerprints at the scene of the crime. You're protecting the server operator, but making it trivially easy to determine which computer under your control is connecting.

Re:Always.

[Nursie]

Any idiot with a network jack can run their own dhcp server.

There are a lot of situations where it would be possible for someone just to plug in and compromise. You're right, it's beyond simple packet sniffing, but it's not leet haxxor territory either. It also assumes that nobody on the link from you to your server is corrupt and intercepting things.

Anyway, I see no reason, if you're going as far as creating a self signed certificate, for you not to go a stage further and create your own signing authority and import its public key as trusted. You don't have to pay anyone and it really isn't much more effort.

I'd also point out that there are authenticationless cipher suites within SSL that are perhaps better suited to this situation.

Re:Always.

[Nursie]

"You are confused, my friend. An SSL certificate, like an earlier poster already pointed out, is only there to encrypt the traffic"

No, it isn't. This is utter bullshit. Go and read up on SSL and how it works. It's there to provide authentication. SSL/TLS provide three things - authentication, secrecy and integrity. Encryption is done using AES or DES (mostly) using keys that are either exchanged under asymmetric encryption (certificate) or more likely and more often using DH or DHE shared secret algorithms.

You can encrypt traffic and perform shared-secret key exhange without a certificate.

A certificate is NOTHING to do with encrypting the traffic. That's all done with symmetric AES or DES.

"It doesn't ensure identity and is not meant to do so regardless of what VERISIGN signup page tell you.
THere is only one way to ensure that you are at the site you intend to: LOOK AT THE ADDRESS BAR. Its why its there for."

Yes, and the certificate contains verification (to a low but reasonable standard) that the server you are talking to is the legitimate holder of that address. Your address bar doesn't know about jim-bob in the net cafe next to you, running his own dhcp server and supplying poisoned DNS info. Or Alec at the ISP who's bored and decided to hack a few random SSL cxonnections with his man in the middle software.

Sorry, but I've read and implemented the SSL v3.1/TLS specifications and I know what I'm talking about on this one. I suggest you get informed before telling me I misunderstand.

Re:Always.

[Anonymous Coward]

Want to show us how MITM can get valid certs?

Re:Always.

[Alpha830RulZ]

Hello, my name is A.Turing Machine.

Re:Always.

[arcade]

The CERT authenticates that you are talking to the site a trusted third party has signed a certificate for. It means that an attacker isn't between you and the site. In other words, it means there are now attacker between you and the phishing site.

You, in other word, knows that you are talking to the site your browser think it's talking to, and not an attacker between you and the site. It does not authenticate the _site_, if that is run by badguys. It authenticates that there is no badguys between YOU and the site.

If you are using paypa1.com instead of paypal.com, and that's a phishing site, well, what you've authenticated is that there isn't a badguy in the middle between you and the phisher. You might still be fooled, though :P

Re:Always.

[naasking]

The CERT authenticates that you are talking to the site a trusted third party has signed a certificate for.

Trusted by whom? Certainly not me, the user. I think the use of such ambiguous language creates a false sense of security.

It means that an attacker isn't between you and the site.

No, but the attacker may BE the site. In other words, certs are not a means of secure introduction.

Saying that certificate authorities are necessary only because they foil man in the middle attacks is a poor justification. There are a plethora of other significant attacks that CA certs in their current form cannot prevent.

Re:Always.

[Anonymous Coward]

also there's the 5 way goatse issue with that site ...

Re:Always.

[Workaphobia]

You're missing a key point: if you can't trust the other end to keep their private key secure, then you can't trust them to keep the data you send them secure either. SSL certificates are only misleading in the way you describe if you expect them to be a silver bullet for all your security needs; if you use them properly in conjunction with good policies, they do indeed provide a guarantee of authenticity.

Re:Always.

[Workaphobia]

I'm sick and tired of no browser implementing a sane policy on this matter. Even firefox, for all its open source rebellious attitude, doesn't dare change the system. You'd think there'd be a free software project that shares this kind of ideal.

Re:Always.

[Workaphobia]

You've expressed this view several times today, and I have to say you don't seem to understand the point of the security model that we use for the internet.

The network is not secure.

The basic network protocols were designed long before security was ever an issue. Since you do not own and maintain physical control over the network hardware, you would have to trust the real owners of the links and routers between you and the destination in order to have a guarantee of authenticity, confidentiality, and integrity on the data sent over it. This model is unacceptable because not every component of the network path is trustworthy.

Consequently, a cryptographic protocol is a necessity for secure communication on the public internet. There is no other solution.

This says nothing about the integrity of the end points of the secure channel, and a hacked machine on either side will compromise the content of the communication, as you've pointed out. What you miss however, is that we don't care to analyze and discuss this prospect. It makes for a very boring system if you can't even trust the endpoints, the automatons executing commands on behalf of real flesh-and-blood users.

As you say, we're "not safe until there are no vulnerabilities": the difference between the hosts and the network is that we have control over the security of the hosts, and an institution as professional and security-critical as a bank is expected to maintain high standards, whereas neither party is in a position to do anything to improve the security of the network as a whole. It is possible to keep the endpoints secure - or if you argue that it is not, the key point is that this is outside the problem domain of network security that SSL was designed to address.

If you expect the simple use of SSL to protect you despite the exploitable flaws in your system, you're going to be disappointed, but not because SSL isn't doing its job. Please stop dissecting our claims that SSL provides authenticity, merely on the basis that the end points could screw up, because we're not denying this. We're simply restricting our conversation to the benefits of SSL in various circumstances, under the conditional assumption that it is the weak point in the system. Anything else is besides the point.

Re:Always.

[Workaphobia]

Arcade is correct. Think of it this way, if the function of a certificate were encryption, why would we need it at all? We can already do encryption using Diffie-Hellman.

Certificates bind an identity (that is, dns identity and not necessarily a real identity) to a public key; they make a claim about the relationship between an entity and a piece of information. This claim is backed up via a signature by a trusted third party.

The simple truth in the model is that if you trust the third party and the known binding of the third party to its own public key and the mathematics of the encryption+signature algorithms, then you trust the binding of the site identity with the key they claim to control.

Now you can certainly debate the effectiveness of a certificate at providing authenticity in a real environment, but that doesn't give you license to deny its basic purpose unless you're intentionally exaggerating for the purpose of sarcastic commentary. But I think you legitimately believe what you say, and are letting unrelated faults in the usage of the system cause you to deny basic aspects of its design.

Re:Always.

[Workaphobia]

Very well.

5. You compromise the user's exception list, by asking for an exception. In this case the user is at fault.

Re:Always.

[arcade]

Trusted by whom? Certainly not me, the user. I think the use of such ambiguous language creates a false sense of security.

Sure, but that's another debate.

No, but the attacker may BE the site. In other words, certs are not a means of secure introduction.

I haven't claimed otherwise. certs are a means of a secure *connection*. It doesn't say anything of the security of the actual site. It never has. It tells you something about the *connection*.

Why are you confused about this?

Saying that certificate authorities are necessary only because they foil man in the middle attacks is a poor justification.

Poor justification for what?

There are a plethora of other significant attacks that CA certs in their current form cannot prevent.

And? What's your point? You have a problem with what the trusted third partys role in SSL is? Then pray, how are you going to solve the man in the middle-problem?

Re:Always.

[naasking]

It doesn't say anything of the security of the actual site. It never has. It tells you something about the *connection*. Why are you confused about this?

I'm not confused. The point is this level of security is insufficient to the point where it's next to useless to most people. Security problems are much broader than secure connections to unknown parties, despite what the CAs claim.

Poor justification for what?

Poor justification for the usefulness and costs of certificate authorities.

You have a problem with what the trusted third partys role in SSL is? Then pray, how are you going to solve the man in the middle-problem?

Secure introduction. You know, an introduction from a party with whom you actually have a meaningful trust relationship.

Re:Always.

[fyngyrz]

Nope. the certificate doesn't do authentication, because that whole idea is a scam. You CANNOT authenticate who you are talking to with any facility provided in the entire encryption chain. Understand? There IS NO AUTHENTICATION. It's B-U-L-L.

Therefore, we are left with looking at what else happens; and the only thing of any use is encryption. Mind you, there are some harmful things that happen, such as technical people get taken in by the illusion of authentication that the CA's are pushing off on the gullible; then the users get taken in, and now we have an environment where people think they are safe, when in fact, they are not; an environment where people think that little lock icon means that they know who they are talking to, when in fact, they do not; an environment where scads of money can be coerced out of businesses so that they are "up to par" with the "standard", which in FACT does absolutely NOTHING with regard to authentication.

Bottom line: A certificate's linkage to the party it is issued to can be completely and utterly compromised literally seconds after it is issued. There is no way to tell if this has happened. Therefore, they're absolutely useless for authentication. However, the encryption path provided by the https connection still protects the conversation from eavesdroppers between the two parties; this in itself is the single use of the mechanism, and it does NOT in ANY way require CAs.

Re:Always.

[fyngyrz]

Wrong. They CAN get valid certs for paypal.com — certs aren't one-up items that can only exist in one place. Fact: The only thing that ties a user's computer to 'paypal.com' is the hosts file and/or the DNS, both of which are easily compromised. A duplicate copy of the paypal.com certificate and key (and even the signing request, if they left that around) can be hijacked (as can anyone else's) and between that and a trivial hosts file compromise, you're screwed. But you don't even need to go that far. Just compromise the browser. The bottom line is authentication via certificates is an illusion, and if you depend on it, you're gullible at best. The consequences of that illusion is an industry that takes huge amounts of money for absolutely nothing of real value in return. They're selling illusion, but because they've convinced the public and gullible developers that the illusion has value, operating without it is exactly like standing up in a Catholic church and telling the congregation you're an atheist. Doing that will get you ostracized, which, for a business, is death.

It's a total scam. Authentication is impossible; encryption is trivial. Neither is worth ten cents. That illusion, however, is worth billions.

Interesting

[Mensa Babe]

"and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA"

So it exists for the distribution of copyrighted material, right? Just like, say, Amazon? Or like SourceForge? So what's the problem of the CA knowing their personal information? After all, the domain registrar already knows the correct data, right?

Or are you saying that they exist for the distribution of copyrighted material illegally, in which case we all couldn't really care less what their problems are, and you should report them to the appropriate authorities instead of helping them break the law?

Now, back to your main question:

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!

Self-signed certificates are pointless, because you are confident than no one is listening but you have no idea who are you talking to. It means the possibility of a man-in-the middle attack and many more problems that should be obvious to any self-respecting, computer-literate, intelligent person.

But what is even more important is the problem of getting people used to trusting incorrect, i.e. "self-signed" certificates. When they later are victims of phishing attacks everyone on Slashdot is saying to blame the victims because they have entered the fake bank website with an incorrect SSL certificate, while at the same time forcing equally incorrect certificates down their throats and saying that it is ok to trust it, because it is "self-signed" (which means that it is signed by itself, for those not familiar with the SSL lingo).

And these are the most important problems caused by self-signed certificates. False sense of security, and getting used to the browser complaining about incorrect certificates and ignoring it later.

Re:Interesting

[locofungus]

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!

But you'd be happy if you'd arranged with your bank for a truck to come and pick up the money, and when the truck arrived and you asked to see his documentation he said "Here it is, guaranteed by Fred Bloggs over there." And you have no relationship with Fred Bloggs (although you guess your bank does because the driver says so!) and no comeback against Fred Bloggs if he screws up even if he does have a relationship with your bank.

Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert. And then when the driver turns up he can say "Here it is, guaranteed by your bank". And if the bank has screwed up and let some third party get hold of their root cert private key then I've got a relationship with the bank and I can sue them.

And when I communicate with my bank I should be able to give them my root cert and then they can check I'm who I say I am (they can use other methods as well if they don't think that is secure enough)

IIRC the hmrc website (UK TAX) allows you to use client side certificates to communicate with them but doesn't allow self signed ones. But why not? Is hmrc more confident that verisign can tell who I am than hmrc itself is? As a result I don't use a client side certificate.

Tim.

Re:Interesting

[marco.antonio.costa]

I thought SSL encryption was about secure comunications ( that armored vehicle you're talking about ), not who is authorized to do what. By the way, anyone stupid enough to give their money to such a truck in the fable you spinned up deserves to have it gone.

When they are later victims of phishing attacks everyone on Slashdot will laugh at them for entering their bank account and password into a site that reads www-we-will-screw-you.mybank.com.

And that is the most important problem caused by third-party signed certificates. False sense of security and paternalistic gov't-like measures that make encryption look like a privileged tool for the ruling elite, and not mere mortals.

Re:Interesting

[Znork]

The answer is: Never.

Actually, the answer is: Always.

if you don't know who you are talking to in the first place?

For most purposes it's sufficient to know I'm talking to the same guy I was last time.

Or would you trust the guy in the truck because he showed you a self-signed document

Instead I'm supposed to trust the guy in the truck because he shows me a document signed by the guy in the truck next to him?

The economic interest of a CA is diametrically opposed to their purpose. They maximize their profit margins by _not_ doing what they should be doing; hence I have no more reason for trusting Verisign (the guy in the truck next to him) than the guy himself.

In fact, I'd be better off establishing my trust once with the guy in the truck, then accepting that trust in the future; trusting the CA merely means I've opened myself up to being blindly tricked coercion of the CA. If the certificate of the person I've established trust with changes I know somethings up. If I'm subjected to a MITM attack signed by a trusted CA I wont even notice.

False sense of security

Funny, I'd say that the false sense of security is exactly what you get from CA signed certificates.

Re:Interesting

[wrook]

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

There is a big difference between knowing who I'm talking to and knowing that I'm talking to the same person I talked to last time. Most of the time I don't care about the former. Do I care that an author is who they say they are? Or do I care that they wrote a specific book?

Most of the time relationships (especially on the internet) are not dependent upon the actual identity of the person I'm talking to. They rely on the history that I've had with that person. And there are many times when I might want to have a secure conversation with someone, knowing that they are the person I talked to the day before. But I usually don't care what their identity is.

In the case of a sales transaction, I agree that knowing the identity of the person is useful (i.e., I know who to chase if the sale goes wrong). But to say that there are no cases where I want to have continued secure conversations with someone without knowing their identity is just plain wrong.

To give you an example, let's suppose I downloaded a piece of software off the internet. I notice that there is a patch to the software. I want some security that the patch is being distributed by the same person I got the software from in the first place. I have no interest in knowing that person's name, where they live, etc, etc, etc. I have a trust relationship with them already and I simply want to continue it.

Re:Interesting

[ren-n-stimpy]

no, the answer is not "never." it is a convenient, extremely user-friendly way to provide encryption when authentication has occurred via a different channel/method.

Re:Interesting

[dave420]

I have to disagree. SSL certificates, regardless of who signed them, are a matter of trust. This site just wants the trust put it in (and not a CA), which you would be willing to do if you wanted to use the site in the first place. Getting all pissy about it like some petulent 8-year-old doesn't change that.

Re:Interesting

[kestasjk]

Self-signed certificates are pointless, because you are confident than no one is listening but you have no idea who are you talking to Once you accept a certificate you can be sure that, from that moment on, you are talking to the same person you were talking to when you first accepted the certificate.

So you can take special measures to ensure that the self-signed certificate is valid, that VeriSign might take themselves with a CA-signed certificate, and from then on you can be sure that you're safe.

So it can be less convenient, but if people know what they're doing (not always the case) it can be just as secure as a CA-signed cert, and it is always more secure than no cert at all. (Which is the most important point, I think)

Re:Interesting

[mystik]

"When is it acceptable to encourage users to accept a self-signed SSL cert?" The answer is: Never.

You realize, however, that this is exactly how SSH works?

The first time you connect to an ssh server, the server sends out it's key. It's self-signed key. And the client polietly asks you "Would you like to accept this key?, here is it's fingerprint" It's now the *users* responsibility to trust that key, via some other secure channel or web of trust. *This* is the only opportunity for a MITM attack, even in SSH.

From that point on, the key is saved, and the ssh client complains loudly when something goes wrong with it.

Self-Signed Certs behave in exactly the same manner. If this site can provide a secure channel to advertise it's correct self-signed key fingerprint, and users cache + save that key, then they get exactly the same kind of security they'd get with ssh.

I do question, however, their decision to use mismatched certs + site names. This will cause the browser to throw up a warning regardless of whether it's cached or not, which will probably desensitize users to the severity of these kinds of warnings.

Re:Interesting

[tepples]

There is a big difference between knowing who I'm talking to and knowing that I'm talking to the same person I talked to last time. Most of the time I don't care about the former. Do I care that an author is who they say they are? Or do I care that they wrote a specific book? If you have a printed copy of the book, how do you verify that the errata web page listed in the book is in fact under control of the author or publisher? CA-signed SSL certificates help you connect an off-web identity to an on-web identity.

Re:Interesting

[Anonymous Coward]

When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

So, how about my running imap / smtp / webmail here in Manchester which gets used by few friends and family in three diferrent European cities? What's the problem with my using an SSL certificate that was generated by cacert.org?

Technically the answer is that my friends and family know it's me and therefore we don't need verisign to verify this - not to my mum at least. Still, the generated SSL cert is fine for what we needed.

Re:Interesting

[mpe]

The economic interest of a CA is diametrically opposed to their purpose. They maximize their profit margins by _not_ doing what they should be doing; hence I have no more reason for trusting Verisign (the guy in the truck next to him) than the guy himself.

Indeed what do Verisign do to validate the whatever in question? In many cases what can they do?

In fact, I'd be better off establishing my trust once with the guy in the truck, then accepting that trust in the future; trusting the CA merely means I've opened myself up to being blindly tricked coercion of the CA.

Or if you needed the equivalent of a CA wouldn't it make more sense for that to be the guy at the truck depot. Who actually has some chance of verifying that the driver is who they say they are. If a truck turns up to a bank to collect cash and it isn't who they expect they will ring the trucking company. They are unlikely to ring some entity unconnected with either the trucking company or the bank on the other side of the planet.

Re:Interesting

[jeroen94704]

Well said.

Of course, securing communication against evesdroppers is important, but in today's world, establishing identity is a far more pressing problem. Something certificates are designed to address. Phishing works, not because people use insecure communication, but because they fail to verify who they're communicating with.

This is understandable too. Humans are primarily equiped to deal with people we know in person. Historically, strangers were deeply distrusted. This has changed in the modern world, where we constantly deal with people we don't know, yet have to trust to some degree. In practice, we use things like appearance, tone of voice etc to identify people, but there is also a lot of implicit trust involved. This works out pretty well, most of the time, because the effort to fake an identity often outweigh the potential rewards.

As with many things, all this breaks down in cyberspace, where anyone can pretend to be anyone else without too much trouble. And while the mechanisms to establish identity do exist, people are unfamiliar with them, and the mechanisms are rather pathetic: Do you really distrust a website that looks EXACTLY like your bank's, just because there's a little padlock in the bottom-right that's not closed?

Tool-builders need to enforce the rules rigorously so people become educated and comfortable with them. Certificates are a powerful mechanism to establish identity. We shouldn't abuse that mechanism for something it's not intended for, simply because it muddles the water between good and bad security.

If someone needs encrypted communication without identity verification, then there are other ways to do this (SSH for example).

Re:Interesting

[Monoman]

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

Mom always said "Don't talk to strangers" but maybe I like talking to strangers anyway. :-)

The point is because I don't want everyone to be able to see my conversations. Encryption and trust are two different issues. They may have a close relationship at times but they are not the same.

Leave it up to me what level of trust to use. If I am going to purchase something online and it will require me to transmit my credit card number then I will determine the level of trust. Keeping it simple, below is a list of options and most folks probably prefer the 3rd.

HTTP - I don't know who I am talking to and I don't care who can hear us.

HTTPS (self signed) - I don't know who I am talking to and I am reasonably sure no one can understand us.

HTTPS (3rd party CA) - Someone I trust vouches for who I am talking to and I am pretty darn sure no one can understand us.

However there are situations where the 2nd is just fine. Maybe I browse some questionable areas of Craig's list from time to time and don't want my mom to find out. I don't really care if the CL is really the CL I think it is. I just don't want mom seeing what is in the packets when she fires up Wireshark (moms do that you know). :-)

 

Re:Interesting

[lusiphur69]

Or are you saying that they exist for the distribution of copyrighted material illegally, in which case we all couldn't really care less what their problems are, and you should report them to the appropriate authorities instead of helping them break the law? Not everyone lives in your digital backwater. Believe it or not, there are countries with forward-looking instead of protectionist IP laws. Further, I hate to take away from your offtopic little rant, but perhaps they don't want to spend the money on a signed certificate? They're not exactly cheap - but I assume you know this since you sound like you work at VeriSign.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place? Yet you do know who you are talking to - the site that provided you with the certificate in the first place. Would I accept a self-signed certificate for online banking? Probably not, however for the purposes discussed it is perfectly acceptable.

When they later are victims of phishing attacks everyone on Slashdot is saying to blame the victims because they have entered the fake bank website with an incorrect SSL certificate We think they are stupid because they are. If you don't bother to verify the URL and instead click on some seemingly legitimate link that appeared in your email without checking where it is pointing, that is the direct cause, as opposed to the client's acceptance of the self-signed certificate.

And these are the most important problems caused by self-signed certificates. False sense of security Uh, I would argue this is the problem with signed certificates. To wit, the famous case where two of MS's certs were 'hijacked' - how that is even possible without colossal stupidity I do not know - now delisted, but for a good while a security threat.

As an aside, I truly hope your sig is meant to be ironic. s-u-p-e-r-i-o-r

Re:Interesting

[segedunum]

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

This adequately demonstrates the fallacy, and the danger, of believing that certificates give this kind of guarantee. Knowing who you are talking to depends on being confident of what address you are putting into the address bar of your browser in the first place (a whole different ball-game not addressed today), not whether the certificate is accepted cleanly by the browser.

It means the possibility of a man-in-the middle attack and many more problems that should be obvious to any self-respecting, computer-literate, intelligent person.

No, and no, you're not computer literate. There is no man-in-the-middle attack at all, but you can have a man-in-the-middle attack if you have another signing authority involved in the process.

Re:Interesting

[Anonymous Coward]

Or are you saying that they exist for the distribution of copyrighted material illegally, in which case we all couldn't really care less what their problems are, and you should report them to the appropriate authorities instead of helping them break the law? It's ok, it's the Pirate Bay. =)

Re:Interesting

[mpe]

There is a big difference between knowing who I'm talking to and knowing that I'm talking to the same person I talked to last time. Most of the time I don't care about the former. Do I care that an author is who they say they are? Or do I care that they wrote a specific book?
Most of the time relationships (especially on the internet) are not dependent upon the actual identity of the person I'm talking to. They rely on the history that I've had with that person. And there are many times when I might want to have a secure conversation with someone, knowing that they are the person I talked to the day before. But I usually don't care what their identity is.

Many of the same issues come up with the issue of personal identity. As Bruce Schneier has mentioned frequently there is often a confusion of identity with intent.

In the case of a sales transaction, I agree that knowing the identity of the person is useful (i.e., I know who to chase if the sale goes wrong). But to say that there are no cases where I want to have continued secure conversations with someone without knowing their identity is just plain wrong.

Even with a sales transaction knowlage of actual identity may not be that important. Or if it does matter it can be discovered "out of band". What matters to the customer is that they get what they have ordered when and for the price they expected. It would not be good if their credit card details were to be misused.
What matters to the vendor is that they get paid. If would not be good if the credit card details they were supplied were bogus or belonging to a card reported lost or stolen. However it probably isn't important that the vendor know if several customer accounts actually relate to the same "person", even if they are all paid by the same credit card or out of the same bank account.

Re:Interesting

[Minwee]

Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!

Actually what the guy is doing is saying "I'm the same guy who showed up last week and the week before, because I have the same certificate." All you need to do is verify the certificate once and it will be at least as reliable as one signed by any other certificate authority.

Why would you feel more comfortable if the guy in the truck had paid fifty bucks to get a signed document saying "I'm authorized to do what I'm doing. Signed: Epstein's Mom"?

Re:Interesting

[Anonymous Coward]

Bullocks.

Exactly why do you trust a certificate seller? Do you know they really care about your security and not just about making cash selling fairly worthless certs?

Exactly what lengths do the cert sellers go to to ensure you are really you? Hint: I could have a cert tomorrow saying I was 'Mensa Babe'. They really don't do an extensive check to make sure you are really you. So the certs don't really mean much at all other than you have a secure connection between yourself and the webserver. A vendor signed cert simply isn't worth much more than a self-signed cert.

If you want to make sure a cert is good, contact the person you want to talk to and get cert number from them.

Re:Interesting

[devman]

Yes, because Fred Bloggs cert will be signed by a root signing authority (or a CA who's cert is signed by a root signing authority) who will have been trusted enough by reputation to be put in Firefox (my web broswer) by its developers. I DO find it reasonable to trust Firefox development team to only use trusted sources for there CA list

See how certificate chaining works?

At some point you have to trust someone, but with that trust comes liability as well on the part of the trusted party. Verisign et al assume liability every time they sign another lower level CA's cert or end user cert. Not just civil liability but reputation liability. Write enough bad checks and developers will stop putting you in their software as a signing authority.

Re:Interesting

[devman]

No, GP had it right. PKI works for the most part. The guy who shows up in the truck (to borrow from the analogy) will have his cert, which is signed by the bank, which is signed by a CA, which is signed by a root CA. All of the people in that chain assume liability. The root CA will be someone trusted by the people who wrote the software you use, and since you installed it on your computer I assume you trust those developers, (if not you can modify your trust authorities list to fit your desires).

On the flip side, if you accept a self-signed cert the first time, and it does turn out to be bogus, the only person liable for that is you the user. Thats why browsers warn against it. Self-signed certs ONLY acceptable for encrypting traffic to an entity that you have first hand knowledge you can trust. i.e. SSLing admin functions of a website I control and run with a self signed cert, or using https to get in to my uTorrent client from work.

Re:Interesting

[tokul]

Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert.

So you trust your bank even when it issues signed and "trusted" certificate of www.otherbank.com

Re:Interesting

[MasterOfMagic]

Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me."

The Internet is not something that you just dump something on! It's not a big truck! It's a series of tubes! Ever see those tubes at the bank! It has to be safe!

Re:Interesting

[locofungus]

If my bank asked me to go to "other bank" in order to pay money into my account at my bank and said "You'll be able to confirm that it really is other bank because they'll have paperwork signed by us to prove it" then yes, I would trust my bank.

I recently got redirect to this site when buying rail ticket from http://www.nationalexpresseastcoast.com/

https://www.securesuite.co.uk/rbs/tdsecure/opt_in.jsp?

I was using a natwest debit card (who happen to be owned by RBS).

The site didn't work properly (I just got a blank page) but it was supposed to be asking me for various letters from a password for my card for the "verified by visa" scheme.

Was it a scam site that didn't work or was it the real site that didn't work? Can you tell from the certificate?

Or should it have directed me to
https://secure1.securesite.co.uk/
instead?

(I've removed all the get parameters that were on the original URL)

What about if I'd ended up at:
https://sourceforge.net/

or
https://www.trustedcomputinggroup.org/?

How can I tell which one of those I should be trusting with my credit card details and which I should be afraid of?

Tim.

Re:Interesting

[Anonymous Coward]

For most purposes it's sufficient to know I'm talking to the same guy I was last time. Certificates are one way of dealing with a different problem: Authentication of mutual strangers. Certificates do not get in the way of checking that the person is the same as last time. You can still verify that the public key hasn't changed. If you don't trust CAs, remove them from your browser and it will treat all certificates like self-signed certificates.

Re:Interesting

[Anonymous Coward]

Are we talking ssl certs purely for ssl/browser types of exchanges?

self signed certificates are used more than just for online banking and shopping.

For example:
IBM Tape Encryption Solution on TS1120 drives. x.509 certs are used to wrap encryption keys that the drives themselves use for bulk encryption of data at rest. self signed certificates are 100% valid for use here as there is no identity proof used/needed for the solution

I can cite several different forms of encryption where self signed certs are used, secure and valid, but the rule of thumb, if its for internal use, and not proving identity, self signed is fine.

Re:Interesting

[locofungus]

Also see my other reply.

I've had certificates signed by verisign (might have been Thwarte - was a while ago now) for a small company. It really isn't difficult in the UK to setup a company and get the necessary paperwork to jump through the hoops to get a certificate.

The problem is that sites like:
https://www.securesuite.co.uk/rbs/tdsecure/opt_in.jsp
I'm expected to trust for everything even when I get unexpectedly redirected to them from another website and yet my certificate looked pretty much identical to that one.

Tim.

Re:Interesting

[tokul]

self signed certificate or own root certificate authority does not have good chain of trust. Asking to install some CA is not acceptable, because that CA can be used to abuse your trust. If browser already has CA certificate preinstalled, its trustworthiness was checked by time and third party. Asking to accept self signed certificate is not acceptable, because users won't be able to differentiate between good and bad self signed certificates and click on "Yes" to get stuff done.

Re:Interesting

[naasking]

At some point you have to trust someone, but with that trust comes liability as well on the part of the trusted party.

Yes, you trust your bank, which is the only entity in this whole scenario with whom you actually have a trust relationship.

Re:Interesting

[ivan256]

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

Are you being dramatic, or do you really mean "never"? There *is* a way to verify who you are talking to. You can compare the key signatures. The only reason *not* to use a self-signed key is if you want some third party to do the validation for you instead of doing it yourself.

Re:Interesting

[drinkypoo]

The situation with self-signed certificates is perfect as it is. You get a warning. You can get certs pretty cheap. You don't need a whole crapload of secure FQDNs although it is fun. As it is self-signed certs work great when you don't want the contents of a connection (e.g. passwords) snooped but when you're sufficiently certain that the site hasn't been compromised. If it has, then losing your password is a minor issue, because you have different passwords on different sites, right?

Re:Interesting

[Znork]

will have his cert, which is signed by the bank, which is signed by a CA, which is signed by a root CA.

See, there's where it breaks. I may trust the bank, and I may trust the bank to sign the truck guys cert, but I neither trust the CA (unless it _is_, verifiably, the bank), nor the root CA.

I assume you trust those developers

Trust them to write software, or trust their judgment as far as deciding who is worthy of my trust? One, perhaps, definitely not the other.

(if not you can modify your trust authorities list to fit your desires)

Which is, a bit simplified, pretty much what accepting (and storing) a self-signed certificate is. I initially accept that the party are who they say they are; trust is then built upon that; as long as I can track the original identity, my trust is against that entity.

Self-signed certs ONLY acceptable for encrypting traffic to an entity that you have first hand knowledge you can trust.

Trusting anyone you don't have first hand knowledge of, in one way or another, is a bad idea.

Liability is, for most purposes, worthless as a replacement for trust. A CA can be compromised in a multitude of ways, ranging from government pressure to software faults; actually recovering any damages would be difficult and most likely not a profitable avenue to pursue.

Re:Interesting

[chill]

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

Never talk in absolutes.

I work for a financial services company that has approximately 300 independent affiliates where we handle back-office processing. Much of this is done thru SSL-encrypted communications, both web and e-mail. We are set up as our own CA and self-signed the certificate. Client certificates are issued to our affiliates that are signed with our cert.

The issue is trust, and our affiliates trust US vastly more than Verisign or any other company. We meet them face-to-face at least once a year, as required by law. We speak with them on the telephone frequently. They don't know Verisign from Verizon.

We instruct them on how to install our cert as a trusted root, so it only pops up the warning once. After that, it will only pop up if there really is an issue.

Re:Interesting

[slim]

because it is "self-signed" (which means that it is signed by itself, for those not familiar with the SSL lingo). Gee, thanks for solving that mystery for the rest of us! I get the impression that many posters think that it means 'signed by the owner', which is a bit more general than the strict meaning: 'signed using the private key corresponding to the public key in the certificate'.

Re:Interesting

[slim]

If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!

Your whole post is right on the money. But just to play devil's advocate, you might trust this unauthenticated man to delivery a low-value parcel in his high security truck. If he then returned, providing a good service again and again, each time presenting the same self-signed authentication, you might then trust him to delivery something more valuable.

Just as in the real world, computer security is all about risk assessment. Unfortunately, the designers of PKI haven't succeeded in making it simple enough that most people can make an educated assessment -- because it's hard.

Re:Interesting

[slim]

Why would you feel more comfortable if the guy in the truck had paid fifty bucks to get a signed document saying "I'm authorized to do what I'm doing. Signed: Epstein's Mom"?

It doesn't say "I'm authorised to do what I'm doing", it says "The bearer of this certificate is John Smith, 23 Foo Street, Bartown".

And it's not signed "Epstein's Mom", it's signed "Trusted Identity Corporation".

So, if your jiffy bag full of diamonds goes missing, you can go to the police and state with a high degree of confidence who had them when you last saw them.

Whether or not you consider "Trusted Identity Corporation" (Verisign, Thawte, whatever) to have done an adequate job of identifying John Smith before issuing him a certificate, is another matter. If you don't, remove their CAs from your browser.

Re:Interesting

[samson13]

I can't think of any good reason not to accept the certificate in this case and some good reasons to accept it permanently.

What it provides:
1) A packet dump in the middle won't show what I was doing on the site (but flow statistics might give it away a bit). Any attack has to be active.
2) It lifts the bar on man in the middle attacks.. Somebody has to do some crypto as well as intercept the traffic..
3) Provides evidence for future connections that there was a man in the middle attack or there is a new man in the middle attack. If the key changes then you know that something is or was wrong.. Start cleaning your hard drive;-)

The alternatives are:
1) Straight http. No advantages over https with self signed certs. Easy to man in the middle and capture traffic.
2) Trusted CA signed cert. The main disadvantage here is that the users probably don't want to tell the CA that they were visiting this particular site. Whenever you connect to a SSL site then your browser SHOULD be doing a OCSP check with the CA to find out about the validity of the certificate. If I was running a dodgy site I wouldn't want my users to be sending this sort of information to Verisign.

I would treat the SSL certificate from my bank differently.

I agree about the problems with normal users ignoring browsers complaining about too many things.

Re:Interesting

[harlows_monkeys]

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

There are a couple points to it. First, sometimes you don't care who you talk to in the first place, but you want to know it is still them the SECOND time you talk to them.

Also, the fact that I'm talking to an effectively anonymous stranger doesn't mean I want everything I say to them public.

Re:Interesting

[Anonymous Coward]

How do security morons like you get modded insightful? What the fuck? It's idiots like you that we can blame for all the stupid fucking once-off self-signed certificates on the internet. I don't know who the site is, I've never visited before, but I'm being asked to trust their certificate. There IS NO PRE-EXISTING RELATIONSHIP. There IS NO "BEFORE".

Fuck you and the moron horse you rode in on. Making the internets less secure by being a FUCKING MORON.

-- Your local TLS implementer, who has finally lost his shit with YOU STUPID MOTHER FUCKING SELF-SIGNED IDIOTS.

Re:Interesting

[Anonymous Coward]

I agree: self-signed certs are fine. check the fingerprints of such certs on an individual basis, like you do when you connect to an ssh server for the first time. When setting up an application that talks SSL protocol, you could know the fingerprint because you ran the installer and it printed the certificate fingerprint. You would have that fingerprint written down to verify on your first connection to the server.

A self-signed certificate is identical in security to a CA signed certificate if what you verify is the FINGERPRINT of the certificate. If you can't be bothered to verify the fingerprint of every certificate, then verifying the fingerprint of a CA is a slightly weaker guarantee.

CA signed certificates will be useful when people are using hardware tokens like smartcards that are generated by a trusted issuer. In relatively tamperproof hardware, there is a useful level of non-repudiation and a reasonable degree of confidence that the user is not accidentally (or intentionally for that matter) compromising the keys.

Re:Interesting

[Anonymous Coward]

You don't really understand how the information security industry works, do you? A CA gets compromised in the way you're discussing, and there's economic hell to pay. They in no way get higher profit margins by compromising security.

In addition, I think you're vastly underestimating the importance of the ability to revoke a certificate. This shows a bit of a lack of understanding of the protocol. The server and certificate can be compromised, and you have a simple way to ensure a MITM attack does NOT occur using your once-valid certificate.

Now it's always better to have encryption than not, so if it's a choice between self-signed or nothing, always go self-signed.

Not really

[John Betonschaar]

It's only giving a false sense of security if people do not trust your web site. If the certificate authority is setup well, the server certificates are created from it like they should, and the certificate authority server is secured well enough (ie: not accessible from the outside in any way) the setup is in no way 'less safe' or trusworthy than using a known certificate authority. It's not like anyone can fake your CA or the client certificates.

Re:Not really

[Anonymous Coward]

If the certificate authority is setup well, the server certificates are created from it like they should, and the certificate authority server is secured well enough (ie: not accessible from the outside in any way) the setup is in no way 'less safe' or trusworthy than using a known certificate authority.

That's a huuuuge IF...

Re:Not really

[evilbessie]

But how do we know that a 'random' CA is trustworthy, what is to stop disreputable companies having their own CA. The point is to give some degree of trust to the system which otherwise could not be trusted. It may be badly managed at the moment or the companies may try to screw you over, but that doesn't stop it being a good idea to have some degree of trust when using certificates.

Re:Not really

[Anonymous Coward]

It makes me wonder why there isn't some sort of caching thing, like with SSH.

If your cert is signed by a root CA then just cache it without complaining, otherwise warn the user then cache it if they want.

If it changes after caching then complain.

Wouldn't something like this be a better prevention against man-in-the-middles with signed certs? Or do certificates change so frequently that it would just get annoying?

But then, who reads pop-ups anyway?

Re:Not really

[John Betonschaar]

Well how do we know that a certificate signed by Thawte is trusworthy then? Almost every piece of unwanted software I ever encountered that used SSL verification was signed by Thawte, they sell certificates to anyone. Yet, it is installed as a 'thrustworthy' CA by default in Windows.

The issue is: people cannot trust the issuer of the certificate anyway, because they know nothing about them. I'm not 100% sure about this, but I think the CA always has to be set-up using the domain name it is valid for, I think you cannot spoof it without getting an invalid certifcate. So as an end user, at least you have the domain name as a reference. The only other alternative is to not use SSL verification at all, seeing that it is pretty easy to get a certificate from a 'trusted' provider.

Re:Not really

[evilbessie]

I said the current system didn't work very well, doesn't mean that it's not a good idea to have this system of trust, it just needs to be better than it is now.

Re:Not really

[John Betonschaar]

Well of course you cannot argue that an infallible chain of trust would be a good thing, but I'm not entirely convinced such a thing can ever exists in this world, where commercial interests and general user ignorance will always provide ample opportunities to use the system to your own ends, creating a false sense of security.

That said, the question in this case was if a user-CA would be a bad thing. I still don't think it's a bad idea if you are careful with the implementation. IE: make sure no-one ever, ever sees the machine with the CA setup with which the root and CA certs where created, except the maintainer (that means *no* network access whatsoever), and the CA certs are only provided to customers/visitors by a secure channel (physical or electronical). If they just import the CA cert once and get the client certs the usual way, they can be pretty safe they're talking to you.

Re:Not really

[Brian Gordon]

Exactly. Why on earth would you not trust the pirate bay to keep their private key secret? Presumably they keep it at least as secret as their logs and since those are the only thing you have to lose, if law enforcement gets their hands on the key, they've gotten their hands on the logs too anyway.

Re:Not really

[Zeinfeld]

No, the certificates issued by VeriSign have three types: Domain validated (only sold on the Thawte and GeoTrust labels), organizational validation (Class 3) and Extended Validation.

Ob disclaimer, yes I work for a major CA, no I am not speaking for that CA here.

Domain validated certificates are designed to enable use of encryption and to provide protection against a DNS or BGP level man in the middle attack. They are not intended to be adequate for Internet banking or for determining if the merchant you pay for that plasma TV is likely to be trustworthy. They are perfectly adequate for sites like Slashdot

The class 3 and EV certificates are both designed to provide accountability and both have similar validation criteria in principle. In practice the EV validation process is a lot more cumbersome and involved because the criteria are determined by a consortium of the major browser providers and CAs.

Accountability is important because a party is much less likely to default if this is likely to result in civil or criminal consequences. In the EV and Class 3 models the accountability is established by verifying with an independent source that a business with the specified subject name exists, that the party making the application has the right to act on behalf of that party.

The class 3 certificate offers equivalent security to the relying party as the EV cert but the relying party is much less likely to notice that it is being used. The EV security experience is much more noticeable and results in a measurably greater degree of customer confidence - as evidenced by lower rates of abandoned shopping carts.

As for self signed certificates, I have been part of the W3C Web Security Context working group for the past year and a bit which has (amongst other things) been working on the problem of how to make use of self signed certificates more useful and how to avoid the problem of the idiotic 'warning' messages that browsers throw up when encountering a self-signed cert. Adding security should never make the user experience worse!

A lot of people are suspicious when I say that I support the use of self-signed certificates. But I really don't see them as a threat to the business. On the contrary, for every domain validated cert user who downgrades to a self signed certificate there will be tens of servers turning on encryption who were not using it at all earlier. And every one of those self-signed certificate users is a potential upsell to a domain validated or organizational validated certificate. I am not aware that any CA has ever marketed email SSL certificates but you will find quite a few mail servers on the net that are using CA issued certificates for STARTTLS transactions.

Cryptography is like sex (hey I did say I was not speaking for my employer): it is much better when you know who you are engaging in it with. And certificates are currently the cheapest, most effective model for knowing who is at the other end of the pipe.

Re:Not really

[Meski]

However, their idea of "good" is completely up to them. Their idea of "good" is "does the cheque clear?"

hipotesis

[alxtoth]

Are you talking about the SSL certificate for "the Pirate Bay"? In that case, yes, it is fully understandable why they can't afford to apply for a proper certificate. And I guess the audience doesn't mind either.

In all other cases it's a big NO NO

Re:hipotesis

[Anonymous Coward]

It's not really a No No; it's just that, in order to be sure that the certificate is okay, you have to be able to ensure that you have the same level of security as a normal certificate. What is that exactly??

Well, a normal certificate is often verified simply by email. In order to get one you have to prove that you can respond to email for your domain. In other words you prove that you get IP packets that are destined to that domain (recieve the email you want). This is quite a bit harder than spoofing, but much easier than breaking an RSA key.

So, how can we get the same level of security? Well, if we connect to a web server then that web server has proven that it can get the packets for that domain. Any certificate it distributes has almost the same level of security as a normal web certificate. There is one difference. When you use a normal certificate they are proving that they can now recive your packets and they could at another time much earlier when they contacted the cerfificate authority. Minor seeming, but important difference. You can gain the equivalent security by checking that the certificate is the same as it was some time before and checking that you have the same certificate as other people world wide.

So a good way, would be for the web site you are posting about to post their certificate fingerprint on various public web sites and news groups known to be associated with them. That would be just as good as a normal web certificate. Or put another way, given the amount people pay for them and the security they advertise, normal certificates are indeed scams.

Please note, this discussion doesn't cover extended verification which is also a partial scam, but not as bad as normal certificates. Please note also, that there are some of the older certificates which also require more than just email verification. That is totally irrelevant since your browser interface doesn't differentiate between them and the hackers will always go for the weakest security.

Re:hipotesis

[Anonymous Coward]

I don't see why they can't apply for a "real" cert.

Quite a few CAs these days use only email to verify that you are entitled to the cert (usually obtained via whois records). Some of them do it for free (cacert.org, although the CA cert is not trusted by many browsers).

I'd be happy to trust a cacert.org CA certificate, but *not* some random CA who could then issue certificates for other sites.

Re:hipotesis

[master5o1]

What he's saying is that it is not necessary for all websites that would like SSL security to have to have a proper commercially signed certificate. For something that is less-risk than a bank they should be allowed to self-sign.

Re:hipotesis

[morgan_greywolf]

Or put another way, given the amount people pay for them and the security they advertise, normal certificates are indeed scams.

Commercially-signed certificates buy you one slight degree of security -- since the certificate is signed by a third party, it means, at least minimally, that someone else trusts the certificate. It's up to you to determine if you trust that someone.

Re:hipotesis

[Mr.Phil]

It's the paper trail for payment that would more for concern.

Re:hipotesis

[Anonymous Coward]

Infact, having a third party signing your certificate potentially reduces it's security, since they are now in possession of the certificate too, and have likely transmitted it to you via plain text email.

Re:hipotesis

[Bandman]

Thawte, my registrar, allows you to login to their website via https and retrieve the cert. Better than email, anyway.

All the signed cert really says is that whoever signed it (the "trusted party") believes you to be whoever the cert was created for.

Re:hipotesis

[slim]

Infact, having a third party signing your certificate potentially reduces it's security, since they are now in possession of the certificate too, and have likely transmitted it to you via plain text email.

HUH?

There is nothing whatsoever that is confidential in an X.509 certificate.

It is a chunk of bytes that says "Public key P corresponds to identity I, according to authority A", and it contains a signature created using A's private key, which ANYONE can check using A's public key.

During the whole request and issue process, the secret bit -- I's private key, never leaves I's possession.

The certificate could be printed in the New York Times, with no loss of security.

Re:hipotesis

[afidel]

There are two problems with using a third party for TPB's cert. First is that it is highly likely that one or more governments would compel the CA to turn over the cert, and it is also likely that the cert would quickly make its way onto a CRL through legal action. Since AFAIK there is no Swedish top level CA it is unlikely that they feel there is any CA that enjoys the same freedoms that they do (it makes me very sad that I as an American am saying that).

Re:hipotesis

[Anonymous Coward]

The certificate signs the public key of the web server. This means that the certificating authority doesn't actually have access to the private key. Assuming that RSA is actually secure (which is pretty much a fundamental assumption for most computer security right now) then possession of the certificate doesn't give you much.

This is good, because in fact the certificate is given out directly by the web server at the start of the SSL connection and before you do your verification of the public key. So in fact everybody who connects to your web server has a copy of the certificate and the public key. Just not the private key.

Re:hipotesis

[jeaton]

The certificate is public. There is no risk in transmitting it in the clear, and it is in fact done everytime you connect to the webserver.

The corresponding key, on other hand, must be kept secret.

You don't send the key to the signing authority, however. You only send a CSR (certificate signing request), which does not contain the key.

Now, that said, any trusted CA can issue a bogus signed certificate with a key of their choosing, and impersonate you, but that can be done independant of whether or not you have ever used that CA. For example, Verisign (or any CA that is commonly trusted) can generate and sign a certificate for "www.microsoft.com" and the majoritiy of browsers in the world will happily accept it as perfectly valid.

Re:hipotesis

[Ronin Developer]

Your "public" certificate is MEANT to be shared. Having a third party sign your certificate implies that the signer trusts your certificate.

So, how does the signer trust the certificate in theh first place? The creator of the certificate self-signs it. Since this signature can be verified by anyone who receives the certificate via its public key, they know the signer holds both the public and private key.

For a third party to reliably sign a certificate, originally it was suggested having a notary verify your identity before signing. Most people don't go that far any more and send the certificate by email. This does not verify the holder of the cert is who they say they are - only that they hold the private key. For most people, that's good enough.

It's perfectly fine to generate your own self-signed certificates - in fact you might want to issue certificates to users and sign those certs yourself. This can be used as a method to limit who can access an encrypted system -if they have a valid client certificate - they can be authenticated. Naturally, you should still use a two factor authentication system - the certs are just one piece of the puzzle.

RD

Re:hipotesis

[Anonymous Coward]

But the buyer of the certificate only meets the third party by email, so the trust can only be as strong as the trust you have in the origin of an email.

Technically the CAs have a verification policy, so you the level of trust is actually a chain of trust. You trust the third party to some degree, and your trust them to follow their policy to some degree, and the employee who follows the policy trusts the email to some degree.

Now if I meet a customer of mine in person, and give them a USB key with my self signed CA certs on, they now have a higher level of trust in my self issued certificates than any from a commercial issuer, providing they install my CA certs into their browser, to validate my website certificates.

Re:hipotesis

[sjames]

Well, a normal certificate is often verified simply by email. In order to get one you have to prove that you can respond to email for your domain. In other words you prove that you get IP packets that are destined to that domain (recieve the email you want). This is quite a bit harder than spoofing, but much easier than breaking an RSA key.

Interestingly, the cert is supposed to demonstrate that the IP traffic HASN'T been intercepted and re-directed. So, if I intercept and redirect BigCo's IP traffic through my router, I can then "prove" I'm BigCo so that I can get a cert that "certifies" that I am BigCo and not some hacker intercepting their traffic!

Actually I would say that a widely published Cert is BETTER than one that some CA has signed. When a CA signs a fraudulent cert it happens quietly. The legitimate entity will be blissfully unaware that they are being impersonated. If someone widely publishes a fraudulent cert there's a chance the legitimate entity will see that and counter-publish the real cert and claims of fraud. You can then use an alternative means of communication to validate one or the other.

Re:hipotesis

[tattood]

Don't signed certs also protect against phishing? When you go to your bank website, their cert is signed by a CA. If a phishing website is trying to trick you into giving them your username, they won't be able to have an SSL website that has the CA signed cert, which should be a red flag to a user that something is not right.

Re:hipotesis

[Digital_Quartz]

The problem is that a self-signed certificate suffers from attacks at distribution time, whereas a CA signed certificate does not.

First, you have to understand what a certificate is. A certificate consists of two parts: a public key, and a subject. The public key has a matching private key, but only the owner of the certificate has the private key (no one else; not even the CA). The subject tells us who the cert belongs to, and it is signed with the private key (so we can use the public key to make sure the subject hasn't been altered).

If I connect to your server via SSL, and you provide me with a self signed certificate, then that certificate proves that you are you (because of the subject), and it provides a means for us to establish encrypted communication (because of the public key). All is well, right?

Well, not quite; this only works if you've provided me with your cert ahead of time via some other secure channel (not the web). Otherwise, this setup is vulnerable to the classic "man in the middle" attack. Someone who wants to intercept our communication pretends to be you, and gives me his own "fake" self signed cert. I establish communications with the attacker; the attacker's subject is signed with the attacker's public key, and the attacker has the private key so he can read the messages I send him. The attacker then establishes communications with you, and passes my messages on to you, and the attacker can now listen in on everything we say.

The attacker could also pretend to be you, again by providing me with a self signed cert that claims to be you.

The problem in both of these attacks is simply that I have no way to verify that this self signed cert is really your self signed cert. If you had given it to me ahead of time, I could have added it to my list of trusted certs, and then when the attacker presented me with a different cert, I'd know someone was up to something. (Although, how would I know it was really you when you give it to me "ahead of time"? And if we have some out of band secure channel, why aren't we using that instead?)

Now, why isn't this a problem with CA signed certs? The CA goes through varying levels of pains to verify that you really are you when you submit a signing request. So I get a cert from you, it's signed by the CA's cert's private key. I check the signature against the CA's cert, and I see that it is good. Since I trust the CA, I know that this certificate really is your certificate.

The man in the middle attack and the "pretending to be you" attack won't work here; if the attacker provides me with a different certificate, then the certificate's signature will either not match the certificate, or else won't have a signature. The attacker could simply grab your certificate (it is provided to anyone who asks for it by your web server - the certificate itself is public knowledge), and then the cert would pass the signature checks, but since the attacker does not have your certificate's private key (only you have that), the attacker would be unable to decrypt any communication I send to him using your certificate.

There's nothing wrong with self-signed certs in and of themselves. You will notice that the signing certificates belonging to the CAs are self signed. This only makes sense; the CA signed your cert with their cert, but who signed the CA cert? Even if someone did sign it (the uberCA), then who would sign that cert? It has to end somewhere, so it ends at the CA.

The thing about the CAs' signing certificates is that they are "well known". Everyone has a copy of them; they come with your operating system. If, for some reason, you distrust your OS distributor, you can go find multiple copies of them scattered about the internet. If you could convince OEMs to include your self signed cert, it would be just as good. :)

Re:hipotesis

[Anonymous Coward]

CA certs sometimes come with your browser, not your OS. If your browser binaries get hacked on some mirror site, all your public keys (ergo trust in corresponding private keys) are belong to us. Phishing would be made twice as easy via MITM, because the fake site now has a valid certificate signed by our evil version of VeriSign. Alternatively, if a particular browser hack allows the attacker to overwrite your certs in memory somehow, an initial phishing redirect can be used to modify the certs as described above without even having to compromise the browser distributor. Both scenarios are worse than a self-signed cert. My opinion is that if someone has control of your network (required for MITM), it's time to hit the bunkers anyway (physical transport of symmetric keys and realtime memory integrity checks).

Re:hipotesis

[vimh42]

Here is the problem though. Why should I trust a signed certificate? If I go to a website and am prompted by an un-signed certificate, I need to determine if I trust that that web site.

If I go to a web site and their certificate is signed so no prompt but I have just blindly put my trust in the web site and in the nameless CA.

Personally, I don't trust the CA's any more than I trust some random website.

Re:hipotesis

[bwcbwc]

Except that the certificate authority also issues the private key at the same time. Otherwise they couldn't validate the signature themselves.

Re:hipotesis

[mibus]

When you use a normal certificate they are proving that they can now recive your packets and they could at another time much earlier when they contacted the cerfificate authority

Assuming you check how recently the cert was issued...

(I still agree that it's more useful than not, but it's not *great*)

Re:hipotesis

[mibus]

I hate replying to myself, but I forgot of course the old can't-do-proxy-MITM-attacks aspect. Duh.

Re:hipotesis

[cbhacking]

A very nice explanation.

I'd like to point out that the above attack is NOT purely hypothetical; my university's computer science security class included a project to implement a man-in-the-middle attack using a self-signed certificate that was indistinguishable from the valid cert - we retrieved the valid cert, and copied all the relevant details off it - except that it wasn't signed by a CA, and the public key it presented corresponded to our attack server's private key. We read everything that went over it in clear text, the real server never knew they were being spoofed because we re-encrypted the data using the server's cert, and the client got only a single pop-up warning (Firefox 3 complains much more bitterly than Firefox 2, which is what we used at the time).

Now, our attack server was a proxy - the client had to configure their browser to use it. However, it would have been trivial to set this up as an apparent open-access router. Use either Linksys or, for example, a cafe's SSID, a wireless card that can be configured to act like an access point (most can, with the right driver), and another network card to connect your MITM attack box to the Net. Configure your computer to act as a router between the two connections, pipe all SSL traffic coming over the access point lookalike through the attack program, and kick back while you read (and log) everybody's encrypted traffic. It's really not hard.

In other words, for all the problems with getting a CA-signed cert, from a user's perspective anything that doesn't have a trusted signature chain is just that - untrusted.

Re:hipotesis

[nobaloney]

The site's private key never leaves the site's host. The authority's private key never leaves their posession.

Re:hipotesis

[slim]

Except that the certificate authority also issues the private key at the same time. Otherwise they couldn't validate the signature themselves. No.

1. User generates a public/private key pair
2. User sends request to CA, containing their public key - nothing confidential here
3. CA verifies identify of requestor by whatever means their process specifies (increasingly lax, it seems)
4. CA creates certificate and signs it with CA private key
5. Certificate may now be given to anyone - it contains nothing confidential.
6. Owner of the private key can authenticate themselves - "Look, I've signed this with my private key. And this certificate proves that the public key you use to verify the signature is mine."

Can you trust a commercial CA???

[Anonymous Coward]

In a world of National Security Letters, can a commercial CA located in the US be trusted?

How can we tell if a CA is confirming government man-in-the-middle attacks as being a valid endpoint?

Are you really connected to your site via SSL/TLS, or is there an automated system intercepting traffic and analyzing it using a compromised CA?

In such a world, self-signed certificates, or hosting your own root CA is the more secure option.

I cannot confirm that CA's such as Verisign, Thwart, etc., can be trusted.

Re:Can you trust a commercial CA???

[Anonymous Coward]

Also, as navigation is performed via FQDNs, there is an additional issue of compromised root DNS systems.

Compromise the CA and root DNS system and you have an instant eavesdropping setup.

Since all these would be under US control and the push for interception of voice and data, I'd say it is a well established practice.

The question is what threat does that pose to foreign governments and businesses?

Re:Can you trust a commercial CA???

[Anonymous Coward]

Of course, you realize that the private key that is associated with your cert is kept on your machine and your machine only during the whole process, right? You simply send a request to the CA saying "this is who I am!" and they send a cryptographically secure reply saying "sound's good, here's what you need to create a cert."

But yeah, MITM breaks that...

where's the article?

[stormguard2099]

Geez, I bet none of you even RTFA before you posted;)

Re:where's the article?

[marco.antonio.costa]

Of course I didn't. This is /., isn't it? ;)

For Testing Only

[Ammin]

IE 7 on Vista and Firefox 3 on Windows will only accept certs using RSA encryption from trusted authorities. The process for adding a trusted root authority in either browser is not particularly user friendly. So if you want anyone but geeks to actually use your site with modern browsers, you really have to get your cert signed by one of the default trusted root authorities.

Re:For Testing Only

[Anonymous Coward]

StartCom Ltd is a trusted root authority in Firefox 3 (and their earlier root cert is in Firefox 2 and Safari 3). They provide free SSL certificates at http://www.startssl.com/

This story reads like...

[The Ultimate Fartkno]

...O.J.'s "If I Did It, Which I Didn't, But Could Have, And Might Have, And Probably Did, But You Can't Prove It, And After All The Bitch Was Really Asking For It, But That's No Big Deal And I'm Going To Go Play Some Golf" manuscript.

No links, no research, no facts, just a gripping headline that has nothing to back it up other than claiming that "a certain web site" did something.

That's some great detective work, Lou...

Trivial question - how about the math answer ?

[OeLeWaPpErKe]

Self-signed certificates are acceptable if you can spread the root public key *yourself* in a secure manner.

Simple, no ?

In any exchange between 2 known parties for example, it is *always* preferable to have self-signed certificates.

Re:Trivial question - how about the math answer ?

[Anonymous Coward]

Distributing the public key securely is not necessary. Distributing it in a way that its integrity can be verified is.

Re:Trivial question - how about the math answer ?

[wasabii]

That's not really self signed then. Self signed is when the priv key signs it's own public key. Creating two keys and having one sign the other is perfectly fine, as long as you distribute the other properly.

Internally

[jamesh]

Only internally, when you have rolled out your trusted root cert to all the users who might access you site (in a secure manner of course).

Or during testing when you have dev.mywebsite.com that you are giving selected users access to for debug and testing purposes. But the cost of a dns validated cert is so low that you might as well just fork out the $$$ and put a proper cert on it anyway.

Development uses only

[JenniP]

I'm a software developer and will often create my own certificates for testing purposes, and in my test lab people will trust them, however out in the wild there is no excuse for not getting a proper certificate signed by a proper authority.

Not only is this coming across as the company trying to do things on the cheap it has the possiblity of unraveling the trust of SSL for places you actually care about. If this becomes wide spread just think of the phishers create a copy of A Bank's site make their own SSL and put a note on the login screen "Dont worry you have to do some work to trust this certificate everything is alright honest guv."

Personally I normally trust self signed SSL certificates for sites I visit if they have them as i know the risks, but to potentially undermine for general users is just mad.

Re:Development uses only

[pimpimpim]

It already happens: I quite often see the self-signed certificate warning when big companies (Deutsche Post, for example), have been restructuring their website and something that was on deutschepost.de went to post.de, for example. I even wrote them about it, but of course no answer or change. In the end, people don't really read the warning anyway :/

Re:Development uses only

[gabebear]

I think schools are probably the worst offenders here. They have important records and still act like security isn't a big deal. For almost a year the cert for https://security.etsu.edu/ was invalid(past it's expiration) and https://www.etsu.edu/ has had the same problem. https://security.etsu.edu/ used to host the script to reset passwords(by entering SSN/birthdate).

What's worse is the library page http://libraries.etsu.edu/patroninfo where you login with the same login/pass that accesses all your other accounts. The library-system doesn't even have an HTTPS server...

At least I can almost forgive the library since they aren't super-technical, but we are still REQUIRED to use straight FTP to upload websites to http://students.etsu.edu/ for several CSCI classes. There is no SFTP access to students.etsu.edu. Yes, this uses the same login/pass we use for everything else...

I've sent several of emails to IT, but generally they don't get answered and I'm just not motivated enough to deal with their byzantine power structure.

I guess I'm done ranting...

Re:Development uses only

[Anonymous Coward]

Umm, is that a self-signed cert warning, or a domain mismatch warning?

Those are different things. One says "I dunno who this guy is", the other "this is really that other guy"

Requirement for a signed certificate SSL flaw

[Chrisq]

In my opinion SSL mixed two requirements, identification of site owner and secure communication.

This meant that many sites applied for SSL certificates just for secure communication. Some certificate authorities virtually issued certificates on request.

To get round they introduced extended validation certificates, which means we really, really validate this site.

They should have allowed secure communication without certificates, and had properly authorised certificates to start with. Since they didn't we have the situation where people have to self-sign

Re:Requirement for a signed certificate SSL flaw

[wtanaka]

Isn't any encrypted communication without some form of identification susceptible to man in the middle attacks?

Re:Requirement for a signed certificate SSL flaw

[asc99c]

In my opinion SSL mixed two requirements, identification of site owner and secure communication. Well that is really just because the way public key encryption works provides both of these. The identification might not be required, but it's there anyway.

Re:Requirement for a signed certificate SSL flaw

[Anonymous Coward]

Yes they are.
However it's an order of magnitude at least more difficult to perform a man in the middle attack than to simply observe the data from the network.

I wouldn't want to trust sending complex financial information with an unknown self signed certificate but I'd be happy to use it for privacy reasons for example. I would guess that a self signed certificate makes it 100 times more difficult to intercept your data than using no encryption. A proper CA signed certificate makes it 100 times harder again.

Re:Requirement for a signed certificate SSL flaw

[tepples]

Well that is really just because the way public key encryption works provides both of these. The identification might not be required, but it's there anyway. Public key crypto verifies that the party you're communicating with now is the same party you communicated with before. Verifying that the party you're communicating with for the first time is the same party who owns a given domain is a separate task, and SSL conflates the two tasks.

Re:Requirement for a signed certificate SSL flaw

[dkf]

However it's an order of magnitude at least more difficult to perform a man in the middle attack than to simply observe the data from the network. (I was going to moderate this thread, but there's sufficient misinformation that I'll reply instead.) There are two sorts of attacks possible, either by snooping or by DNS poisoning (well, there are more, but those are the main two). Snooping is defeated by encrypting the channel. DNS poisoning (and other types of man-in-the-middle attacks) is defeated by ensuring that the person/server at the end is who you think it is. The best way to do that is if you already know the public key of the other party, but that's completely impractical for anything other than very small networks. Certificate Authorities are a workaround for this (as are PGP/GPG-style webs of trust) and all they should do at a basic level is guarantee that the certificate for foobar.com is only issued to the owner of foobar.com. Higher levels of assurance are possible (e.g. by binding the name of the owner or owning organization in the certificate) but they're optional. Without that basic identity guarantee, it'd be trivial for phishers or other low-lifes to insert themselves between you and the other party, and you'd have a nice properly encrypted conversation with a bunch of masquerading scum.

Re:Requirement for a signed certificate SSL flaw

[dkf]

Verifying that the party you're communicating with for the first time is the same party who owns a given domain is a separate task, and SSL conflates the two tasks. This is a good thing, especially for non-technical users. There's no way that you can educate people to the point that they'll all understand security, and it's all too easy to lose existing contexts (disk crashes, "helpful" cleanup programs, etc.) You also want to be able to renegotiate the level of security (e.g. if the previous crypto algorithms used got broken).

Re:Requirement for a signed certificate SSL flaw

[StartCom]

It's not just there, it has to be verified or it's not there. When visiting mozilla.org which has a certificate from a legitimate CA issued to mozilla.org AND Mozilla Foundation than you can be pretty sure that this IS the site of Mozilla and nothing else.

You might even want to give them money (and/or provide your credit card or whatever) but ONLY if they are really Mozilla and not some fake site taking your details, right!? That's why identity validation isn't just there, it's there when it's verified (usually)!

Now, you know the site of Mozilla, but what about a site you never visited but still want to provide your details and/or make a purchase? Then you probably prefer to know who they are before doing so...and some known authority confirming that they are who they claim to be.

Re:Requirement for a signed certificate SSL flaw

[skeeto]

In my opinion SSL mixed two requirements, identification of site owner and secure communication.

You can't have secure communication without identification, or else you will be extremely vulnerable to a man-in-the-middle attack, making that secure communication no longer secure at all. You can have identification without secure communication, but, as identification (the key management headache) is the hard part of the whole deal, why not take the extra tiny effort to secure the communication as well?

We basically have two ways to verify an identity without doing a direct face-to-face (not literally, as it could be a phone call, for example) verification: you trust someone else to do it (centralized, a CA as it's done with SSL certificates), or you have a line of trust through people you trust, through people they trust, etc., going all the way to the third-party (decentralized, a web of trust as used in PGP). If you want to dump having an expensive signing authority but still secure your communications with new web servers, some kind of web of trust system needs to be designed and implemented.

Notice, the web server in question can't provide contact information (phone number, address) for key verification because you don't know who sent you the contact information! Could be the man-in-the-middle providing his phone number, awaiting your call.

Re:Requirement for a signed certificate SSL flaw

[asc99c]

Yes this is correct.

What I meant is that the public key decryption process involves using your own private key and the other side's public key. As well as security this allows the receiver to see the data arrived un-tampered-with from the correct sender - only they can have encoded something that decrypts with their private key.

So to verify identity you only have to have a registry of the public keys. It's not like SSL invented a whole new chunk of functionality to provide this identification side.

Re:Requirement for a signed certificate SSL flaw

[noidentity]

They should have allowed secure communication without certificates

What good is secure communication with an unknown third party? The data you receive can't tell you whether it's the party you think it is, because a third party can stand in the middle and simply relay things both ways.

Re:Requirement for a signed certificate SSL flaw

[Talennor]

They should have allowed secure communication without certificates . . .. The problem is that a prerequisite to secure communication the way our current encryption works in an Internet setting is authentication of who you are talking to. Otherwise you don't have end-to-end encryption, which is effectively clear-text communication.

The authentication comes from the PKI certificates. An encrypted channel is then built upon that trust.

Re:Requirement for a signed certificate SSL flaw

[jonaskoelker]

This is a fairly long post. Here's the short version:

We don't have self-signed certificates because the CAs' didn't do the job properly. We have them because they solve a problem that isn't the CAs' job to solve.

(and I think people may be misusing self-signed certificates) ...Now, onto the long version...

In my opinion SSL mixed two requirements, identification of site owner and secure communication.

Saying that something is secure raises the question "against what?". I would prefer to say that the two requirements going into SSL are identification versus confidentiality and authenticity, which I think captures the security requirements you had in mind.

(Remedial crypto-lingo: authenticity means the receiver receives what you sent; confidentiality means no one else learns anything about the message).

This meant that many sites applied for SSL certificates just for secure communication.

Which is rather silly of them, really. If you give up identification---that is, the trusted (although, I think your point in part is, not very trustworthy) third party's verifiable statement that key x is connected to person y---you get the same security as with self-signed certificates: you get a authentic confidential communication, you just don't know with confidence who you're talking to.

For some scenarios, this might be okay. As a non-cryptographic example, I know that Simon Tatham wrote putty, and that he wrote a puzzle collection. Is his real name Simon? Does he live where he claims to? I don't know, and I don't care (no offense, Simon). His identity, in my eyes, is the connection from putty to one entity and the connection of the puzzle collection to the same entity. Identity is association, and all I want to associate is one chunk of code with another.

For a cryptographic example, the identity of Sourceforge, in my mind, is one establish through associating things that only happen on the net: oh--this project is on sourceforge, oh--that project is on sf, oh--my project is on it. In that case, I would be happy to receive a self-signed certificate, and trust that certificate to vouch for sourceforge (and sourceforge only). Then, I would know that it's always the same sourceforge I'm connecting to (which is what I want), but not who I'm actually connecting to (which doesn't have any meaning to me anyways).

For others, it is not. When I contact my bank, I want to know that the web page is associated with something that isn't on the web: the bank's physical presence in my country (its big money vault, its staff, its stocks as listed on the stock exchange). I can't verify this over the web, so I need someone to do that for me. This is the service performed by the CA.

These covers the cases when you want authentic confidential with and without identification. I can't right now imagine a scenario where I would want identification but no confidentiality or authenticity.

They should have allowed secure communication without certificates, and had properly authorised certificates to start with. Since they didn't we have the situation where people have to self-sign

I agree with your second point: they should properly verify (to the extent reasonable, of course) that the certificates they sign are only going to be used by the entity named in the certificate.

Your first point I don't completely understand. They did allow secure communication, since you don't need a CA if you just want a plain old unauthenticated key exchange (such as Diffie-Hellman). The standard way to do unauthenticated key exchange in today's software environment is, for practical reasons, with self-signed certificates.

So, like I said in the short version: self-signed certificates is not an inferior solution to the problem, it's a perfect solution to a different problem.

That being said, the case may very well b

Re:Requirement for a signed certificate SSL flaw

[Christian]

With respect, you're completely wrong primarily because you haven't defined "secure communication". In your head you probably have a vague idea about what this means, probably something along the lines of the traffic being encrypted. However, anyone who knows virtually anything about cryptographic protocols understands that, in practice and for virtually all applications, merely encrypting data sent across a link does not give overall security. Authentication of the remote site is, with very few exceptions, just as important as encryption. There are very, very few applications where having an encrypted conversation with an unauthenticated party is of any value. It's not relevant when sending your credit card details, your bank account number and PIN or even logging into some miscellaneous website. Any sites that apply for SSL certificates just for encrypting traffic probably don't understand this principle either -- but that is clear because (rightly or wrongly) if they really just cared about encryption then they would just use self-signed certificates anyway. Note that the weakness involved in the authentication performed by CAs prior to issuing certificates is an entirely separate issue although the problems this has highlighted why authentication is a vital prerequisite to virtually any secure communication.

This has got to be..

[Anonymous Coward]

..the most stupid reader's question ever to get posted.

It's at least as secure!

[locofungus]

IMO, self signed certificates can be more secure. And for the site in question there's a risk of governments strongarming the certificate authorities to provide signed certificates so the government can launch MITM attacks.

I have a https website on my home machine that occasionally I connect to from work.

Now I get a popup about how the certificate issuer isn't recognised etc.

If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)

Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.

Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated.

(Actually I have a single self signed root cert that I then use to sign all my other certs rather than each cert being self signed)

It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank.

I'm surprised we don't already see spam attempting to get people to install new root certs. (Or maybe we do - almost all the spam I get gets stopped by greylisting or caught by spamassassin)

Tim.

Re:It's at least as secure!

[Nursie]

"If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)

Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.

Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."

Umm. No.

These attacks can be very very easily automated.

1 - Spot SSL connection and become a proxy.
2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair.
3 - sign this with a random, and still unknown CA
4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.

Your popup stays and looks the same (unless you're into reading the public key). Your traffic is all being logged and read.

Solution - take your public key/certificate from home and put it into your browser at work. Otherwise you have absolutely zero protection from snooping.

"It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank."

No, they haven't. They've built a business out of having their root certificates in everyone's browser, and being fairly reliable at verifying that the server you are talking to is owned by the same guy they sold the certificate too. That is all they do.

Your bank could easily become its own CA, all it would need to do is send out a CD with it's public key to its customers. But then you have distribution issues and all sorts of other things....

Re:It's at least as secure!

[locofungus]

Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."

Umm. No.

These attacks can be very very easily automated.

1 - Spot SSL connection and become a proxy.
2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair.
3 - sign this with a random, and still unknown CA
4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.

I disagree.

The MITM has to somehow determine whether the client knows the root cert or not.

If the client knows the root cert then the MITM has to sign the new certificate with a root cert known to the client (and in my case the supposed MITM controls the client and therefore can always do this)

If the client doesn't know the root cert then the MITM has to sign the new certificate with a root cert unknown to the client.

In case 1 the interception is completely invisible. You have to explicitly go and check the certificate to see if the root cert has changed from the expected value. And if you do nothing at all then everything will work.

In case 2 you will get a popup and you will have to accept the cert for the session. If you chose not to "view details" and check the fingerprint then that is your choice but you've still got to make an explicit choice whether to accept the certificate or not.

In the case of wholescale interception of every ssl connection the assumption will be that the client will know the root cert.

Tim.

Re:It's at least as secure!

[Nursie]

"I disagree.

The MITM has to somehow determine whether the client knows the root cert or not."

Nope. Not necessarily, if we take an opportunistic approach.

I have an incoming server certificate.

a) Is it something I have signed with the stuff I have access to? OK, we'll sign a new one and snoop.
b) Is it something signed by someone else? OK, well I'll take a gamble and create a CA and server certificate using the details from the incoming server certificate.

This stuf is fairly trivial to implement by the way. Thanks openssl :)

You end up with four scenarios -

1) Client talks to internal trusted system that our snooper has access to the keys for - MITM is possible and invisible.

2) Client talks to external trusted system that our snooper does not have access to keys for. Client does not have server public certificate - MITM is possible and invisible using opportunistic certificate creation. You're expecting the popup and the certificate details are the same.

3) Client talks to external trusted system for which it has the trusted certificate - MITM requires client to accept your dodgy cert.

This becomes even more insidious if we add a rule 3 to our opportunistic snooper -

c) Was it signed by a recognised public CA? Then I'll leave it alone.

Now you have no idea, your system works the same way whether our snooper is there or not, but he gets to listen in on your communications if you're talking to stuff he controls, or if you're talking to unverified, non-mainstream certificates.

The only way to catch him at it is to use verified non-mainstream certificates.

I'm sorry, but your little "This cert isn't trusted" box is not giving you the assurance you think it is.

Re:It's at least as secure!

[Nursie]

Three! I meant three scenarios!

Re:It's at least as secure!

[Anonymous Coward]

"If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)"

What?
Getting the pop-up to disappear is the -hard- part. It is easy to make the pop-up, just forge your own cert and do a MITM. I suppose you check the fingerprint of your cert every time you connect? Then you, as on of the five people on earth that do that, would be ok.

And controlling the root certs in your browser does not give them the ability to decrypt your traffic. If you connect to https amazon.com, they are going to use a real CA. If they right cert is in your browser, it will recognize it, but that doesnt give anyone the ability to decrypt. It is public key encryption, anyone can see the public key, but the comm is still safe.

Now, since they can replace your browser software itself, they could play some games. But that has nothing to do with the safety of the SSL infrastructure.

Explain to me how Self signed certs are more safe. Cuz the down side is, they are going to train everyone on the internet that you should just click 'ok' anytime a website has their own cert, and then we might as well not have SSL.

Re:It's at least as secure!

[locofungus]

I don't thing you've actually read my original post. Either that or you haven't understood.

The MITM can add root certs to the client and has a root cert in the client that they can control.

Yes, it's possible for the MITM to make any site behave the way it used to. That is by definition and there's no way to prevent it.

But you have a choice of ways it works for sites that you control.

1. No popups etc. Everything looks identical. Only if you decide to go and look at the certificate independently of your browsing will you be able to detect that your expected root cert has been substituted. If the phone rings as you connect you might even forget whether you've actually checked it this time or not when you return to your browsing.

2. Popup every time. Now you have to make a decision whether to accept that root cert every time. Of course you can always just press OK. Then your security just degenerates to case 1. But you explicitly have to make the choice _not_ to check the certificate.

I do check (especially if I'm at a web cafe). And I also know the first couple of words of the fingerprint of the cert.

Of course I could also check by bringing up the cert but I have to remember to do that.

Tim.

Re:It's at least as secure!

[Nursie]

"The MITM can add root certs to the client"

You're right, I did miss the part where you said they control the browser.

If they control the browser then you're already shafted.

Re:It's at least as secure!

[cbhacking]

No offense, but you're assuming that somebody who bothers to set up a MITM using a trusted cert (rather than the quite easy approach of an MITM using an untrusted one) isn't going to notice that the site you're requesting lacks a trusted cert? Wow... that's going WAY out of your way to validate (pun intended) your use of self-signed certs. In your case there's no problem, but trust me - you'd be safer adding your home server's cert to your trusted certs store. Otherwise, the next time you connect to your home machine from anywhere remote, over any network that your don't control the whole path of (i.e. any network outside your LAN), you're not going to know whether the warning you get is because your home server's cert isn't trusted, or because somebody's running a MITM on you.

Re:It's at least as secure!

[locofungus]

No offense, but you're assuming that somebody who bothers to set up a MITM using a trusted cert (rather than the quite easy approach of an MITM using an untrusted one) isn't going to notice that the site you're requesting lacks a trusted cert?

Think about this. Lets assume I'm going to be the bad guy launching the MITM. Lets also assume that I've got the Verisign private key from verisign. Lets further assume that I can mount a MITM attack against you. (maybe I'm the NSA or something)

Case 1: You connect to a site that is using a cert signed by one of the big CAs. It's 99.9% certain that your browser will accept this cert without a warning so I should generate a MITM cert signed by verisign.

Case 2: You connect to a site that is using a cert signed by someone I don't recognise. Lets also assume that you've added that cert to your trusted list. So I should still generate a MITM cert signed by verisign so that your browser generates no warning.

Case 3: You connect to a site that is using a cert signed by someone I don't recognise. But you haven't added the cert to your trusted list. Now I should generate a MITM cert signed by something random so that your browser does generate a warning.

But I, as the NSA, cannot distinguish between case 2 and case 3. So I might just as well sign everything by verisign. And in case 3, the only warning you will get is that the popup doesn't appear which you are more likely to miss than that an unexpected popup does appear which would be the effect for case 2.

The problem that I'm trying to solve is "Is this the same machine I connected to last time". If you're using SSH then the first time you connect to a machine you get a message along the lines of "Host key not recognised: do you want to continue" and depending on your paranoia you can check fingerprints, call up the sysadmin etc to make sure you've got the right machine. After that it's silent unless the host key changes at which point you get a message along the lines of "WARNING HOST KEY HAS CHANGED. SOMEONE MIGHT BE DOING SOMETHING NASTY. AGENT FORWARDING DISABLED".

Browsers don't do that. And I don't know why not. At the end of the day it doesn't really matter who signed the original cert - if you trust verisign then the first time you connect to a site, if you get a verisign signed cert then you can just accept it. If you don't then you'll have to do some more investigating. But after that, if the key changes for that site then you should be worried.

Of course, I suspect that many websites change their keys arbitrarily and don't get the same csr re-signed each year but just generate a new one. But that is a problem with the website, not with the way certs ought to be being used.

Tim.

The site is

[Anonymous Coward]

http://what.cd/ - the private music torrent tracker that spawned after oink.me.uk/.cd was taken down by the British police last year.

Tons of them

[evilpenguin]

I find a self-signed certificate is useful on many occasions. I use it for my own squirrelmail service. I have set them up for "extranet" applications for small business clients.

This is just fine. I give them a hard copy of the key signature and tell them to verify it before the accept it.

Someone above says the a CA adds nothing. I don't agree with that. They add identity verification *to the extent* that site visitors actually *read* the certificates and evaluate their level of trust in the CA.

Quick: Tell me right now how many CAs are in your browser's trusted certs list. Now tell me where that list came from. Tell me why you trust it.

In other words, the signed certificate system can provide excellent security, but most of us simply trust our browsers when they don't complain. That isn't security. You really should check certificates every time. View the details, check the signatures, verify the integrity of your trusted CA list. But who bothers?

So while I don't agree that CA signed certs "add nothing," I do agree that hardly any users (including me who theoretically knows better) do their due diligence that would make that system truly work.

Re:Tons of them

[Cow Jones]

Someone above says the a CA adds nothing. I don't agree with that. They add identity verification *to the extent* that site visitors actually *read* the certificates What's worse, they would have to do that *every single time* they visit an SSL protected site. The vast majority of users will not be bothered to do that, and I include myself here.

There are tools to make checking certificates easier. I'm currently using a Firefox add-on called "Petname", which lets you assign "pet names" for certificates that you've seen and checked once. When the same certificate is encountered again later, the name you assigned is displayed next to the URL (with green highlighting). The UI is very very simple and easy to use, and the cert key is stored with your bookmarks, so it will even sync with Foxmarks. It's not the solution for everything, but it gives you the ability to spot a changed certificate at a glance.

Of course, this implies that you trust your browser, and the Petname tool. Well, it's either that, or no netbanking for you. Security isn't. You have to decide who to trust (open source browsers and extensions help a hell of a lot), and put in a "best effort" to be secure.

and evaluate their level of trust in the CA. This is harder, and I don't have a ready solution for it, other than the "many eyes" method of open source software like browsers and distributions.

I wonder...

[hummassa]

If someone does an inside job of compromising a bank's certificate, how much time would you think the certificate would be on the wild without being revoked? I bet enough time to do a lot of damage.

Re:I wonder...

[jamesh]

If someone does an inside job of compromising a bank's certificate, how much time would you think the certificate would be on the wild without being revoked? I bet enough time to do a lot of damage.

Not nearly as much damage as would have been done if everyone used self-signed certs. Look up 'man in the middle' attack.

Re:I wonder...

[evilpenguin]

Certificate key signatures can prevent MITM attacks. Provided someone doesn't MITM the signature exchange...

CAs are good, but, as I point out in another comment, most of us treat them magically. We don't do anything to verify our trusted cert lists. Can you tell me right now *with certainty* where your trusted CA list came from and that it hans't been modified by someone hostile or by hostile code?

If you can't tell me that for sure, then you are *less* secure than someone using unsigned certs who has personally verified key signatures face-to-face.

Re:I wonder...

[iivel]

All of my certificates on this workstation start with DoD ... and I had to put them there myself. Now on my laptop, it's whatever came pre-installed from HP. I may have to have a look at that later...

Re:I wonder...

[Anonymous Coward]

I partially agree with you. Just explain me what is the process that everybody should apply to "personally verify key signatures face-to-face" ?

Especially without prior knowledge of the other side !

On the other side, if you correctly filter which CA are trusted in your browser and which aren't, you get a practical solution to this problem.

Re:I wonder...

[wasabii]

False dichotomy. You present two options: ultra paranoid verify everything; and verify nothing. There is in fact a third option: trust MS to publish a list of well established and trusted vendors, and trust those vendors to vouch for a sites authority. That is a third option. And for most people it's the preferable option. If not, it would not be so.

Re:I wonder...

[OolimPhon]

False dichotomy. You present two options: ultra paranoid verify everything; and verify nothing. There is in fact a third option: trust MS to publish a list of well established and trusted vendors, and trust those vendors to vouch for a sites authority. That is a third option. And for most people it's the preferable option. If not, it would not be so. Yeah, well, you lost me at "trust MS".

Re:I wonder...

[Bandman]

In order to really use a stolen cert, they would also have to compromise DNS. Any time you attempt to put a cert for one domain on another, the browser freaks out.

It would be much easier to register a one-off site (www.citibonk.com or something similar) and get an actual certificate for it, signed by a trusted party, and use that.

All I ever check for is that the little lock is clicked. I never look at the certificate unless there's a problem.

Re:I wonder...

[Anonymous Coward]

I'm more worried about MOTS attacks (Man Over The Shoulder)

you heard it here first.

Re:I wonder...

[gnick]

Can you tell me right now *with certainty* where your trusted CA list came from and that it hans't been modified by someone hostile or by hostile code? If you can't tell me that for sure, then you are *less* secure than someone using unsigned certs who has personally verified key signatures face-to-face. You can't even verify *with certainty* that the person you're talking with face-to-face isn't some impostor in a clever disguise who has infiltrated your org trying to provide you with a false key. But you accept an appropriate level of risk depending on what level of security is required. Is it likely that you're speaking face-to-face with an impostor? Not remotely. Therefore, that's a good enough verification for damn near everything - I'd even trust it with national security info. Is it likely that a CA list has been modified by somebody hostile? Based on their visible track record so far, no. So I trust them even with bank/medical/SSN etc.

Excessive paranoia buys you a little bit of added security, but at what cost? Very little is black and white - Your optimal solution is almost always in the grey.

Re:I wonder...

[Anonymous Coward]

Yeah, we should trust Debian instead.

Re:I wonder...

[xrayspx]

DoD certs aren't necessarily any more trustworthy, viz: https://www.cheyennemountain.af.mil/

I feel safer already with the public site for one of the most secure military installations in the country on an expired cert signed by an untrusted authority.

/yes I know it's closed now, yes I know the site isn't run from there, please don't be that pedantic. The point is, the DoD doesn't necessarily renew all their certs, even though they sign them themselves. This one is two years expired.

Re:I wonder...

[Anonymous Coward]

https://www.cheyennemountain.af.mil/ ...... /yes I know it's closed now, yes Closed, are you kidding? Everybody knows that it is the place where SG-1 operates from. The Stargate is real!

THE TRUTH IS OUT THERE, man!

Re:I wonder...

[Anonymous Coward]

Registering a cert for a one-off site I'm sure will tip off the CA to what you're doing.

But if you are using a one-off site, you don't really need a cert anyway, because anyone who is stupid enough to think that citibonk.com is a legitimate site has no clue what a certificate is anyway.

Re:I wonder...

[AF_Cheddar_Head]

Um, no Cheyenne Mountain is not closed. I would argue that whether or not a public facing site has a current certificate has nothing to do with the security of the rest of the installation.

It might not hurt to contact the WebMaster and bring it to his/her attention, or maybe I will as I currently work in CMAFS.

Re:I wonder...

[sjames]

Furthermore, have a look at the CA list in your browser. (In Firefox: preferences->advanced->encryption->view certificates->authorities). Now, have any idea who those are? If not, then you're taking a stranger's word for another stranger's ID.

Re:I wonder...

[Cerebus]

Certificate key signatures can prevent MITM attacks. Provided someone doesn't MITM the signature exchange...

Now it all hinges on what you mean by "signature exchange." If you mean intercept the exchange of certificates and substituting a different one, this is detected by the validation process through the issuance chain. Try it.

You don't get that with self-signed certs.

Re:I wonder...

[xrayspx]

That's what I was getting at with the "Yes I know the website has nothing to do with the security of the installation" above. Unless some important people made some really bad decisions.

It's cool to think of the site running on the WOPR, but I really hope it isn't.

I was under the impression that the facility wasn't actually doing anything critical anymore. I don't know where I got that idea, since looking at the Wikipedia page, it clearly looks like it was just upgraded in 2005.

In that case, they definitely should update their cert, but they took no action when I sent email 18 months ago when I noticed it was broken.

Re:I wonder...

[Mr. Slippery]

Now, have any idea who those are? If not, then you're taking a stranger's word for another stranger's ID.

Unless you're building your browser from sources you've vetted or had vetted by trusted parties (using a compiler you've, etc.), you're already placing total trust in your browser vendor. Doesn't do you any good to get a list of trusted CAs from another source and feed them to a browser you don't trust.

Re:I wonder...

[sjames]

Very true. The whole thing just demonstrates that the CA signed certs don't mean nearly as much as the FUDish dialog boxes imply. Too many people drinking the Kool-Aid.

Re:I wonder...

[bwcbwc]

This brings up one situation where I would trust a "self-signed" certificate against one issued by a public certificate authority. This would be for internal use within the company itself. The company can establish its own certificate authority for internal use in authenticating/encrypting internal communications and avoid a lot of the risks of MITM.

Re:I wonder...

[augahyde]

There is in fact a third option: trust MS to publish a list of well established and trusted vendors, and trust those vendors to vouch for a sites authority. You have got to be kidding me! Have you ever looked at the list of trusted CAs? I dare you.

Re:I wonder...

[Free the Cowards]

Ridiculous. Any hacker who feels like poisoning your DNS can generate a self-signed certificate in five seconds flat. Subverting the infrastructure for keys signed by certificate authorities is vastly more difficult. When I visit my bank I can have reasonable (note, not absolute) assurance that I am talking to them, due to how the certificate authority system is set up. If they used a self-signed certificate then I would have to trust my ISP's routers and DNS servers to be doing the proper thing that day.

Re:I wonder...

[sjames]

I said not nearly as much, not that they mean nothing. Of course, all those CA signed certs haven't stopped phishing.

Of course, there's a lot of CAs in the typical list, and few have any idea who most of them are. Given the potential amount of cash that can be grabbed by masquerading as a bank, I wouldn't be that surprised to hear of someone managing it because way too many CAs accept a fax on company letterhead and a promise that it's legit as "proof enough" to sign a cert.

It would make a lot more sense to have the browser simply indicate the level of trust in an authentication somewhere. From encrypted, but no trust to absolutely trusted (only happens when the user has placed a particular key in an absolute trust list).

Re:I wonder...

[fluffy99]

Actually I trust the DOD root certs a hell of a lot more than I trust the commercial CAs. It pisses me off that Microsoft keeps adding new ones to your trusted list via automatic updates without asking.

Re:I wonder...

[xrayspx]

I trust them too, but Firefox doesn't, it not only reports that the cert has expired, but that it's an unknown issuer. Safari appears to have no problem with the root cert.

Re:I wonder...

[iivel]

I was under the impression we were discussing the CA and root chains ... not the cert itself. In this case, I have the CA trusted (and was what I meant when I said they started with DoD ... the DOD CLASS 3 CAs), which means this cert is doing its job. It is expired, but for me, comes from one of my very few trusted sources. Since I'm intamately familiar with the certificate chain, and request methods --- I'm pretty sure that in this case I can trust the source of the cert.

Re:I wonder...

[iivel]

You have to add the issuer yourself to the trusted root list....that's what we were talking about I thought? (All of the random ones that other vendors stick in there)

Re:I wonder...

[xrayspx]

Yeah, that DoD root cert seems to be in the default trusted issuers for Safari, but not for Firefox. So on my machine, Safari complains about an expired cert, and FF complains about an expired cert from an untrusted authority.

Re:I wonder...

[fluffy99]

Yeah, the expired cert is an administrative/management issue. As far as Firefox not having the DOD root certs installed by default, you might consider that a good thing if you're not located in the US. I find it irritating that MS will install root certs for almost non-existent CAs and yet not install the DOD root certs.

Re:I wonder...

[iwein]

Very true. When I teach my security class I always start explaining Authentication and Authorization. The thing I want the students to take home is that security is broken on Authentication by definition, but there is no reason to make it worse.

If you authorize somebody to do something you're always taking a risk, you should minimize that risk as much as feasible by doing your best at authorization. That's as good as it gets.

Re:I wonder...

[Workaphobia]

Can you tell me right now *with certainty* where your trusted CA list came from and that it hans't been modified by someone hostile or by hostile code?

If you can't tell me that for sure, then you are *less* secure than someone using unsigned certs who has personally verified key signatures face-to-face.

That is true, but trivially so. Someone who has verified key signatures in person is always more secure than someone relying on a third party, regardless of how much trust you have in the third party and what you know about the integrity of your CA list.

I believe you're much more likely to be caught by a bad certificate that you allow as a temporary exception, then you are to be caught by a bad unsecured web browser or CA list download. When you're downloading a new version of a web browser you're likely safe at home, where Mitm attacks are more difficult. But you may check your webmail, forum accounts, bank accounts, etc., anywhere. Public wifi, hotel networks (a family member got compromised by this), and so on.

As long as you trust the CA...

[a302b]

Accepting a certificate ultimately comes down to trust. For example, most people trust Verisign. Therefore, if a certificate is signed by them, most people will think: "Here is a legitimate site with identifiable credentials accepted by Verisign."

A self-signed certificate encrypts your data just as well as any other. However, you need to trust the website you are at (and hence the signing authority). The reason people trust sites like Verisign, is that it is often difficult to know how legitimate/secure/etc a particular website is. Also, a website could be faked.

I'd trust a self-signed certificate from my bank. But I wouldn't necessary trust that the site I am at is actually my banking website (instead of a cleverly copied phishing scam).

Also, even if I trust a site, I wouldn't necessarily trust the people they trust. What I mean is that if a certificate is signed by an external CA, or with a mismatched domain, I would have to know and trust that CA or other domain before I would accept that certificate.

Considering that most people just click "OK" when something pops on their screen, I would say that Verisign and the like are useful for now. But I have nothing against self-signed certificates in principle.

Re:As long as you trust the CA...

[Anonymous Coward]

Accepting a certificate ultimately comes down to trust. For example, most people trust Verisign. Hmm... I wonder about that.. i think most people are *FORCED* to trust Verisign, as their root cert is included in the popular browsers, and they are oblivious to that it is even in there...

I dont remember ever making the choice if I trusted Verisign (or any other cert authority) for that matter.

Re:As long as you trust the CA...

[Znork]

For example, most people trust Verisign.

They do? I certainly don't. Verisign has given me no reason to trust them, in fact, their corporate history, actions, statements as well as the judicial climate of their legal venue have given me plenty of reasons to explicitly distrust them.

The reason people trust sites like Verisign

I'd say the reason people trust Verisign is that it gets installed in their browsers by default and they cant be bothered to check. You could install RusChin Phishing Corporation as a default CA in peoples browsers and they'd trust that. So it comes down more to people trusting what their browser vendors put as default CA's. So do you trust Microsoft? Your Firefox distributor? Do you trust the judgement of someone who considers Verisign trustworthy?

Also, even if I trust a site, I wouldn't necessarily trust the people they trust.

Exactly. And the conclusion one can draw from that is that it's simply better to establish trust with each separate entity, or otherwise simply not trust them.

Re:As long as you trust the CA...

[tepples]

I'd trust a self-signed certificate from my bank. But I wouldn't necessary trust that the site I am at is actually my banking website (instead of a cleverly copied phishing scam). Would you trust a bank's self-signed certificate if you can ask an account rep at any branch for the fingerprint on a business card?

Firefox 3

[Trogre]

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load.

I've found it rather annoying, since all our internal web applications are served via SSL.

Re:Firefox 3

[fyoder]

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load. Yup. It appears they're in competition with other browsers for who can create the greatest illusion of security. I think they may be winning.

Re:Firefox 3

[Rovaani]

Can't you just generate your own root certificate, use it to sign all the web-app certs and then distribute your own root certificate to all the employees?

Re:Firefox 3

[hrtserpent6]

Less forgiving? Maybe the first time.

All of our internal websites have self-signed certs. Once I added the permanent exception once, I never got another popup - unlike on FFX2 which gave me a box every time....

Re:Firefox 3

[Thiez]

Why don't you add the root certificate to you browser? In Firefox 3: Tools -> Options -> Advanced -> Encryption -> View Certificates, then add the root certificate to your list of authorities. If memory serves me well, that should do the trick.

Re:Firefox 3

[Thiez]

Indeed you can. The distribution would be the important part. Emailing the root certificate to you employees would be stupid since email can be intercepted and changed (unless you sign it but you can't if the receiver doesn't have the certificate yet... a 'chicken or the egg' problem), so an attacker could insert his own certificate in the email and play man-in-the-middle between the company and the emloyee(s) in possesion of his certificate (for most businesses this scenario is relatively unlikely). Giving a very cheap memory-stick containing the certificate to every employee would work (if you trust the ones handing out the memory-sticks). In the end, it comes down to how paranoia you are :)

Re:Firefox 3

[Minwee]

It's even easier than that. Just distribute a URL pointing to your root cert, click on it and then say "Yes" a few times. Bam, it's a trusted CA now.

By the way if you interpreted this as meaning "Give everybody in your company a copy of the private key for your root CA", then please stop using SSL right away. You may have a little more reading to do.

Re:Firefox 3

[Anonymous Coward]

Which takes more work: doing what you said, or being annoyed by having to click through a few dialogs a few times?

Hell, if this was really an inconvenience, I'd switch the company's browsers NOT to use Firefox, since it's actively slowing down my employee's work.

This is really a bug in Firefox 3. Having to click 8 times to use a self-signed cert. is ridiculous.

Re:Firefox 3

[Anonymous Coward]

I think it actually works better. It allows me to save certificates one off. Since I remove all of the delivered CA certs, this makes things work closer to how things should have been done in the first place.

Re:Firefox 3

[dkf]

Indeed you can. The distribution would be the important part. For larger organizations this is not a problem as they can push the additional root certificate as part of their standard software installation.

Re:Firefox 3

[Anonymous Coward]

Why isn't this modded higher? This is exactly what the parent should be doing.

Re:Firefox 3

[hab136]

Can't you just generate your own root certificate, use it to sign all the web-app certs and then distribute your own root certificate to all the employees?

Of course he can, and I've done this. Distributing and maintaining your own certificates requires a level of control and communication in your company that many businesses do not have. Most companies do not have security experts; they have sysadmins or developers who might or might not know anything about practicing security.

Re:Firefox 3

[Penguin Programmer]

It's even more annoying with error pages turned off.

Re:Firefox 3

[MROD]

It's even worse with embedded controllers which generate a new, self-signed certificate (and other credentials) with every reboot!

You may add an exemption this time but far a reboot you have to do it all again. It makes FF3 totally unusable for this use.

Re:Firefox 3

[bigtangringo]

cacert.org

Using a "mostly secure" CA can introduce it's own security problems, but as far as I know their track record is pretty good.

Re:Firefox 3

[GWBasic]

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load.

On Mac, Firefox 3 only complains once. Afterwards, it always accepts the certificate, even if I quit Firefox and reboot. This, IMO, is a nice tradeoff then the typical approach.

On Windows XP (Not sure about Vista), you can type certmgr at the command-line to bring up a utility that will allow you to install a trusted root server. This will allow you to have an internal root server and avoid issues that occur with browser pop-ups.

Re:Firefox 3

[ProfessionalCookie]

Fortunately you can add permanent exceptions- I actually like this better than FF2's behavior.

Depends on who your users are

[QuasiRob]

If all you want to do is encrypt data then a self signed cert is fine, the trouble is the general public don't know this so when that pop-up appears in their browser they worry and you lose their trust.

As earlier posters have said, there is absolutely no reason to trust a commercial CA - you've never met them, you don't know who they are or what they are doing. The only reason to buy one of their certificates is because it keeps your customers happy.

An alternative, if it can get enough support? cacert.org

Re:Depends on who your users are

[Anonymous Coward]

An alternative, if it can get enough support? cacert.org

MOD UP!

Seriously. Cacert seems to be the perfect solution. You get a central authority that verifies that you own the domain, yet it's still free.

The only thing missing is browser support. It seems to already be adopted in alot of distros according to this:
https://issues.foresightlinux.org/browse/FL-1458

Re:Depends on who your users are

[Anonymous Coward]

An alternative, if it can get enough support? cacert.org

Yes. MOD UP x2. CAcert does seem like a good way.. and it looks like it has been an issue on Mozilla's plate for quite a while.
It has also created quite a few obstacles for both Mozilla and CAcert. https://bugzilla.mozilla.org/show_bug.cgi?id=215243

I really hope that this gets through.

When you do your own trust check

[Kjella]

A SSL certificate, even if not from a trusted party has a stable fingerprint you can use to verify it. Hell, the threat of verifying the fingerprint it often enough. Like in this case, TPB don't need to be certified to any real person or organization. They just need to have the fingerprint published well enough people will agree this is the real Pirate Bay(tm) and not some MITM attack. And don't forget that SSL, unsigned or not protects against an attacker that can only read and not write data.

Depends.

[Anonymous Coward]

A symmetric cypher combined with a random key provides the encryption. The rest of the system is only there to ensure that the parties who have the key are actually the endpoints, and that necessarily includes the authentication of their identities. The possibility that the certificate owner may not have been sufficiently diligent with his secret key is a problem which all cryptographic systems share. Nevertheless, identity verification is important for protecting against trivial man-in-the-middle attacks and certificates or trust-webs are ways to perform that verification. They're not perfect, but they're the best we have for encryption between mutual strangers. If the other party cannot be trusted to properly handle cryptographic keys, you might almost just as well not encrypt at all.

If you store the public key, then a verifiable signature is still important when the web site's public key changes. (That includes the first connection when you change from no key to the current public key of the web site.) The alternative would be to establish a different trusted channel for key verification. That could be a phone call, if it's sufficiently unlikely that you'll end up talking to the same man-in-the-middle who tries to pass his key as the web site's key. Just reading the self-signed certificate and clicking OK? You could be talking to a third party and would only notice when they stop intercepting connections between you and the web site.

Honour Amongst Thieves?

[Anonymous Coward]

So your concern is that you can't trust a self signed certificate from a pirate website?!?!? There's an interesting cognitive dissonance present in the very question...

Control of the certificate? What about the key?

[Chuck Chunder]

This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

What do you mean "control" of the certificate?

The certificate isn't secret information, it's sent publicly at the start of every ssl request.

The private key is the part that means only the proper person can establish an SSL connection certified by that certificate. Incompetence aside there is no reason that should fall in to the hands of someone unauthorised.

If you add an exception for a self-signed certificate then you basically have to trust that the first time you hit a site you aren't being hit by a man in the middle attack.

With a CA-signed certificate then you are basically trusting the CA has done at least some (even if it's only domain control) authentication.

They're technically correct, but....

[jimicus]

A self-signed certificate doesn't detract from the security, this is true. But a real certificate does place an (admittedly low) barrier to entry against fraudulent sites.

Windows has spent the last 15 years encouraging people to click away the dialogue box without reading it. Encouraging the use of self-signed certificates will lower this barrier to entry by encouraging people to think "ah, it's still secure so it's OK".

Re:They're technically correct, but....

[Nursie]

A self signed certificate absolutely does detract from security. It means that anyone can do a man in the middle attack and see exactly what's going on.

Re:They're technically correct, but....

[jimicus]

Sorry, what steps does Windows take to "encourage" people to click away the dialog box without reading it?

People do it, but I didn't realize that was somehow Microsoft's fault. I must be new here.

Then you've probably never watched a computer newb at work.

The first few hours, they'll read every dialogue box, engage brain and make a considered decision before choosing what to click on.

Sooner or later, though, they conclude that the correct answer to any "Yes/No" is always yes and they stop reading the boxes.

What doesn't help is that most of the yes/no, abort/retry/cancel boxes are part of the Windows API - the developer doesn't have to design the box, they just ask Windows to throw up such a box and come back to them with the user's answer. So every question is worded with a "Yes/No" answer. Sooner or later a developer does this but sets up the question so that "No" is actually more likely to be the correct answer and the user can't figure out why the application doesn't work.

What are you protecting ?

[AftanGustur]

To answer your question about when a self-signed certificate is acceptable:
It depends on two factors:

1. What are you protecting
and
2. Against whoom.

When you know the answer to those two questions, you will know the answer to your initial question,

Depends what you're signing

[Toreo asesino]

For simple websites, why not, but for complex service-oriented systems, absolutely not as working around eronious certificates requires you deliberately code exceptions for.

Bad licences ultimately give you a bad testing environment, and seeing how SSL certs aren't expensive, I would say get SSL certs where possible.

How so?

[Chuck Chunder]

ALL sites would be more secure with a self-signed certificate than plain HTTP

How so? Both are susceptible to a man in the middle attack. In the self-signed certificate scenario the man in the middle merely needs to generate their own self-signed certificate.

That's slightly more complicated but not enough to deter anyone if the information is even vaguely snoop-worthy.

I agree however that the certifying authorities are largely rip-off merchants.

Re:How so?

[Anonymous Coward]

Encryption without authentication protects against passive snooping (but not against active attacks). Plaintext communication does not protect against passive attacks.

With wiretapping legislation being passed around the world, default encryption would at least require active, packet-altering attacks, which could be detected by interested parties, whereas passive snooping is practically undetectable.

It would indeed be beneficial if browsers always tried establishing SSL connections and treated connections with self-signed certificates exactly like plaintext connections.

Re:How so?

[norton_I]

Passive eavesdropping is often more technically practical than man-in-the-middle.

Self-signed certificates are just as good at signed certificates at defending against passive eavesdropping.

Signed certificates are part of a defense against MitM, but only part. Such attacks are still possible.

The SSH method of certificate distribution is also reasonably secure in practice without requiring signed certificates. The first time you contact a given host, the key is accepted with notice. After that, changes in the key trigger a warning, so unless the man in the middle was there from the beginning, he will be detected. For some applications this would work OK, not for others.

Current CA practice is a joke. Even if verisign goes to much effort to validate your identity, there are plenty of CAs who will just hand out a certificate based on the email listed in the whois record. And your browser treats them the same unless you actually view the certificate for a specific site.

Re:How so?

[Eivind]

Because what typically happens is the first time you visit such a site you're asked if you want to accept it this time or permanently. You typically click on permanently.

Now, granted, this -first- time you could already be fucked. But assuming you aren't, you'll now have a chance of discovering it in the FUTURE if someone does try to pull a MiM attack on you or similar.

You'll have a chance of noticing this because the browser will ask again if you want to accept the certificate, or even better, the browser could say: "Warning: Certificate has changed" like ssh-clients do.

Also, https protects against passive eavesdropping, even when the lack of a trusted signature means that MiM is still possible. Defending against ONE attack is worthwhile even if OTHER attacks are still possible.

Re:How so?

[Chuck Chunder]

I don't disagree with what you say in principal, however I do not think that if self-signed certificates were in widespread use like that people would become conditioned to ignore the warnings completely, which would be a net loss to security.

It's one thing to ask the sort of people using SSH to understand what's going on. It's another for the general populace.

Re:How so?

[Eivind]

Besides, the certificates aren't technically -needed- to prevent eavesdropping. They're only needed to prevent MiM.

It should be possible to set up a certificate-less https-host, in which case you'd get security against passive eavesdropping only, but no guarantees against active MiM attacks.

It'd be a sort-of halfway-solution. But it -is- a real problem today that tiny and small websites don't have any reasonable way to use encryption at all. Self-signed scares people away (and infact gets perceived as MORE dangerous than plain http, due to the warning)

Re:How so?

[Chuck Chunder]

But it -is- a real problem today that tiny and small websites don't have any reasonable way to use encryption at all. Self-signed scares people away (and infact gets perceived as MORE dangerous than plain http, due to the warning)

Godaddy sell perfectly usable certs for about $30 a year. It's not free, but it's not particularly expensive either. That said I'd like to see them come down to around their domain prices, there is no more work in their domain only signing process.

Key distribution

[c_g_hills]

Using self-signed certificates inside an enterprise is fine so long as all the clients have the certificate authority's public certificate installed. Key distribution mechanisms like group policy make it simple.

Sadly Firefox makes it less secure because it uses its own key store rather than the host operating system's, so users must manually import the certificate before attempting to visit an SSL-secured website.

Re:Key distribution

[MichaelSmith]

Using self-signed certificates inside an enterprise is fine so long as all the clients have the certificate authority's public certificate installed. Key distribution mechanisms like group policy make it simple.

Sadly Firefox makes it less secure because it uses its own key store rather than the host operating system's, so users must manually import the certificate before attempting to visit an SSL-secured website.

I can think of scenarios where this would make firefox more secure and a browser which uses certs from the OS.

Re:Key distribution

[Burz]

I'm pretty sure I read that Firefox 3 was specifically going to address the keystore issue.

Re:Key distribution

[Anonymous Coward]

Sadly Firefox makes it less secure because it uses its own key store rather than the host operating system's Fortunately, Firefox uses it's own key store, because that enables users to make their own decisions about who they trust, rather than trusting their sysadmin or OS vendor to make that decision for them. In theory. What happens in practice might be different. But I think it's nice to think there might be at least a few places where users are allowed to think for themselves.

Re:Key distribution

[c_g_hills]

Alas not. See here for more information. It is listed under "Uncertain" so it may not ever get implemented.

PirateBay?

[Anonymous Coward]

and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA.

PirateBay, is that you?

In that case, I see no problem with a self signed cert, all you want is the encryption.

Re:PirateBay?

[Anonymous Coward]

and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. this bit right here highlights the idiocy of the post.

TPB does NOT exist to distribute copyrighted material, or they'd have been shut down by now, in any country.

TBP exists as a torrent indexing service. What you put on those torrents is of no matter to the index service, just like google doesn't care if its britney spears, or bach. It all gets indexed.

I can't beleive I actually had to spell that out on /.

google adsense

[Anonymous Coward]

It seems that the google adsense site also uses an unsigned certificate ...

Both ways are good

[salarelv]

In my opinion should browsers support self-signed certs by default because there are thousands of intranets for private use where there is no need for a CA certified cert. Like somebody said before secure web mail access is a important issue. For me is it important that the cert is coming from the same server where I'll try to log-in and nothing more. If the browser could detect that and only hint that this is not a CA certified cert - not to pop-up some warnings - would be just fine. I'll see also benefits for a CA certified certs. Like for pay-pal, banks, government sites I'll need certainty that the information I am currently posting isn't going to wrong hands.

Re:Both ways are good

[Nursie]

For the billionth time - If there isn't either 3rd party authentication or a certificate esxchange done via on offline method then you are vulnerable to a man in the middle attack if you accept self signed certificates.

Re:Both ways are good

[salarelv]

You are always vulnerable to a "man in the middle attack". There isn't any secure way to exchange messages with an another party without being in danger of some kind of attack (even offline). My point is that people need some kind protection which isn't expensive. I didn't wrote about the danger of some sort of attack. I am talking about encrypting my packets to some kind intranet or webmail which ensures me that nosy admins or kids who are trying to read packets in a public WIFI couldn't read my private messages with ease. When You have some info about things that is so interesting for somebody that they are ready to make some kind attack then it is better to exchange this info in private.

Re:Both ways are good

[Nursie]

Again, you've missed the point.

"I am talking about encrypting my packets to some kind intranet or webmail which ensures me that nosy admins or kids who are trying to read packets in a public WIFI couldn't read my private messages with ease"

A self signed certificate does not give you this protection.

Public wifi is a great example. If you're going to accept a self signed certificate then you might be talking to anyone. I could really really easily put something on my wireless router's firmware to detect SSL connections and be a man in the middle. All that happens is that it becomes transparent proxy and it creates a new, self signed certificate, telling you that it's the site you're trying to connect to.

A nosy admin could set this up easily. If you haven't got the authentication aspect (which is why things are signed) then you don't have any guarantee that your encrypted packets are going where you think they are and being decrypted by who you think is decrypting them.

Now, there's no reason not to have an in-house or private CA for your systems, so you don't pay Verisign or Thawte or whoever, but you should always distribute the trusted private key for the CA beforehand.

Re:Both ways are good

[salarelv]

Yeah, I know that the sys admin could do it. My point is that it makes it harder and when it isn't so easy to attack somebody then many so called hackers give up. Of course WIFI is a damned security hole but my point is that when You need sometimes these kinds of access (You never know when) then You would feel more secure when You have a self-signed cert than nothing. I am sitting right now in a public WIFI at my universities library. It is completly unprotected - no WPA nor WEP - but I'll know why it is so. The hassle with sharing keys to hundreds of people every day is too big job. Therefor I would be happy if my webmail client has some kind of protection even if this doesn't scare off experienced sys admins but helps to avoid nosy IT students (I have done it myself to show that WIFI is a f***ing security hole).

Re:Both ways are good

[Nursie]

Well, the best way to go about it is to set up your own signing authority at home. This is really easy with openssl and/or the gnu TLS suff.

Then you sign your webmail server with it and import your own public key from the CA into your browser.

Viola - you have secure, authenticated SSL without paying anyone else a penny :)

Re:Both ways are good

[salarelv]

Yes this is a possibility but I really speaking for the masses not for my self - most apps of mine are secured. I just wondering why isn't there any decent way to do it.

What Are You Getting?

[segedunum]

This is timely, as I'm looking at implementing SSL for a web system at the moment, and I'm seriously pondering using self-signed certificates. Paying for a certificate from an authority is, quite frankly, a rip-off. The companies don't need to do anything for that money, and the notion that they provide some service where you can trust the site for the issued certificate is laughable. The only reason for doing so is so that peoples' browsers don't complain when they come across a certificate they don't recognise.

The cynic in me believes that Firefox and IE are giving you all sorts of 'helpful' warnings these days, not to protect a user's security, but to push website developers into buying certificates.

Using certificates is about one thing - encrypted communication between browser A and server B. That's it. Certificates have never given you any guarantee as to the integrity of the site that you're visiting, and it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. To give a guarantee like that, further technology is needed.

As a rule of thumb, if you have a finite number of users logging into a system then a self-signed certificate is OK, and even preferable. If you have some kind of site where the users you can have can be anyone (shopping site for example), then it's preferable to buy a certificate - if nothing else, to keep people from getting infernal warnings popping up in their browser.

Re:What Are You Getting?

[rugger]

You should get a proper certificate signed by a CA. With a proper certificate, the end user's web browser can verify that your certificate did actually come from your web server, and not some other random computer pretending to be your web server.

The reason why browsers complain about self-signed SSL certificates is not because they are self-signed, it is because they cannot be verified as coming from your web server. If you set up your own root certificate and install it into your user's web browsers, then it stops complaining.

If browsers stopped complaining about certificates they cannot verify, I'd definitely NEVER use the web for anything secure ever again.

Re:What Are You Getting?

[Archon-X]

C'mon. You can get a CA signed cert for $12.95.
That's $4 more than a domain.

There's no excuse for not having a CA signed cert.

Re:What Are You Getting?

[MichaelSmith]

If browsers stopped complaining about certificates they cannot verify, I'd definitely NEVER use the web for anything secure ever again.

How do you know for sure that they always complain?

Re:What Are You Getting?

[MichaelSmith]

This is timely, as I'm looking at implementing SSL for a web system at the moment, and I'm seriously pondering using self-signed certificates. Paying for a certificate from an authority is, quite frankly, a rip-off. The companies don't need to do anything for that money, and the notion that they provide some service where you can trust the site for the issued certificate is laughable. I don't know how your system works but I should point out that you can get end to end encryption with SSH tunnelling.

Re:What Are You Getting?

[rugger]

What browser silently allows unverfied certificates?

Sure, if I get hacked and my web browser replaced by a cracked version, then it could happen. No security can even be perfect because you do have to make some basic assumptions.

Assuming that Man in the middle attacks are too difficult to perform is a very dangerous assumption to make.

Re:What Are You Getting?

[Anonymous Coward]

Make your own root certificate, sign certificates for your apps with that, distribute root certificate to the users with instructions to install them (or install them yourself if possible). Forgot to mention the most important step: PROFIT!

Re:What Are You Getting?

[BandoMcHando]

You could try http://cert.startcom.org/
They provide free SSL certificates I think. (Not tried them, YMMV etc)

Re:What Are You Getting?

[discogravy]

Where are you getting 13$ SSL certs? and more importantly, are their certs automagically included in IE/FFox (because if not, you might as well make your own CA and push your own root cert out to your users).

Re:What Are You Getting?

[Archon-X]

http://www.namecheap.com/ / http://www.rapidssl.com/

They're just the same as your expensive SSL certs, but just come from a company with a name less 'known' [but never revealed to the users..], as opposed to Thwarte.

Re:What Are You Getting?

[Deadplant]

Using certificates is about one thing - encrypted communication between browser A and server B. That's it. That is not correct.

Certificates have never given you any guarantee as to the integrity of the site Correct.

it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. Actually, that is the ONLY reason certificates exist.
You do not need a certificate to encrypt communication.
Certificates are an identity authentication tool.

Obviously it cannot ensure that it is Fred on the other end of the line. It only ensures that it is a computer with Fred's key. It is up to Fred to keep people from stealing his key and impersonating him.

If you are considering using SSL on your new website I suggest you go and read up on it.

Re:What Are You Getting?

[asdfghjklqwertyuiop]

Using certificates is about one thing - encrypted communication between browser A and server B. That's it. [...]it gives no guarantee whatsoever of who you are talking to

No they aren't. Also, there is no point in encrypting between A and B if A and B have no idea who each other are. A or B could in fact be one of the very people you're using encryption to protect your communications from. You have no idea.

Re:What Are You Getting?

[Braino420]

Using certificates is about one thing - encrypted communication between browser A and server B. That's it. Certificates have never given you any guarantee as to the integrity of the site that you're visiting, and it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. To give a guarantee like that, further technology is needed.

Encrypted communication between browser A and server B is done via public key encryption, which does not require a certificate at all to work. Certificates are used to bind someone's public key with an identity, that's it. You are correct, no one EVER would say that it is a guarantee, of which there are very few in security. This isn't a black and white issue. You can't just say, "Oh, well, they don't work in these few cases, so we should drop them completely." Certificates DO provide a certain level assurance to the user that I do believe is worth something. They also DO make MITM attacks much harder.

Granted, most of the protection simply comes from public key encryption. Even if a self-signed certificate is used, a MITM will not be able to insert their own certificate, even if it is self-signed, without the user getting a warning in their browser that the fingerprint has changed. But what about the first time that user connected to the website? If the user is expecting a self-signed cert, then the MITM won't have a problem. That is when certs come in. The MITM would have a difficult time getting a cert signed by a CA for a domain they don't even have access to. It's possible, no one said it wasn't, but it's unlikely and requires extra work by the MITM. And that's work that most wouldn't even bother doing, when there are far easier ways (social engineering) to get information you want.

Re:What Are You Getting?

[jonaskoelker]

The cynic in me believes that [IE is] giving you all sorts of 'helpful' warnings [...] to push website developers into buying certificates. Microsoft is in Verisign's pocket? Please share, it must be some good tobacco ;)

I can see the (very contrived) profit motive of a "bad" firefox specifically on ubuntu though (Mark Shuttleworth was involved in Thawte, a CA), but you talk about firefox in general.

and it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. Here's my razor, made up on the spot: never attribute to stupidity what can adequately be explained by ignorance (it's unnecessarily offensive, for one).

Now, care to share your knowledge? I'm thinking that the domain name of the certificate owner is baked into the certificate. Sure, they might let others use *.webhosting.bankofbumfukistan.com, but I think there's a competitive advantage in not doing that.

What am I missing?

Better than the alternative

[slim]

The alternative to accepting individual certificates, is for 'Hypothetical Piracy Enablers' HPE to create their own CA, and for you to accept their CA certificate as a trusted signer.

There's nothing technically difficult about becoming a CA. OpenSSL can handle the bit-twiddling aspect with no problem. The hard bit about being a CA is all the authentication that's supposedly done before signing a certificate, and the risk and liability responsibilities taken on.

It sounds very convenient to accept HPE's CA certificate -- but wait -- that would mean that if some crook could persuade HPE to sign a certificate for (say) hsbc.com, your browser would accept it every time.

So, in this case, since you probably don't trust the signer all that much, it's better to accept the self-signed site certificate.

Root on CD

[tepples]

In the self-signed certificate scenario the man in the middle merely needs to generate their own self-signed certificate. Not if the bank has already given me a copy of its root certificate on CD when I opened my account.

Re:Root on CD

[Leebert]

Not if the bank has already given me a copy of its root certificate on CD when I opened my account. If you have the bank's CA certificate, then just import it, and you won't get a warning anyhow.

Re:Root on CD

[Chuck Chunder]

What's the difference there between using a general CA?

Other than the fact:
-It will cost more for a bank to distribute it's CA cert to all it's customers than to use a general CA.
-It's less convenient for customers, it's an extra hoop to jump through and they'd have to retain the CD and reuse it if they get install a new browser or get a new PC.
-It'll be an even bigger pain to do banking from their mobile phone etc.

There's no advantage to the bank or the customer, only downsides.

3 instances of when Self-Signed SSL is right

[bucktug]

1. Test box
2. When you have a smaller user base of users that actually know you. Like a workgroup that might uses a web front end to a database that isn't usually public facing but for whatever business reason isn't behind a firewall.
3. When you are cheap.

Blah blah... price of everything... cost of nothing... blah blah...

*COUGH...

[jberryman]

*COUGHpiratebayCOUGH

Trouble is, SSL does two things and users are dumb

[fuzzyfuzzyfungus]

The problem with SSL, and the tension between ID verification and simple encryption, is not so much a technical issue as it is a "people, on average, cannot be trusted for anything more complex than tying shoelaces". With depressing regularity, studies show people with no clear idea of what the "lock icon" means, no understanding of the fact that a picture of a lock displayed on a website and a lock icon in a browser are two vastly different things, and no real idea of how certificates work, or what a Certificate Authority actually is.

To compensate, browsers have ratcheted up the warnings given about self-signed certs to extreme levels, making them essentially useless for any site or service catering to the general public. This, then, creates a demand for cheap certs, which leads to shoddy verification, which defeats the purpose, which leads to E.V. certs, which are what certs are supposed to have been all along, only more expensive and with a snazzy green bar that nobody understands. Fan-Fricken-tastic.

What we really need is a clear distinction between "identity" certs and "stability" certs. Identity certs would essentially cover cases where trust in a given entity is a function of official verification; e.g. when I walk into a bank, my level of trust is based on the legal status of the bank, is it an FDIC member, where is it incorporated, are its financial data properly disclosed, etc. In this case, an assigned SSL cert is just one more official aspect of the entity.

The stability cert is different. It maps roughly onto the class of interactions that are based on reputation and patterns of behavior. You don't trust your best friend because you've checked his official ID, and you know that he is who he says he is, you trust him because you have been able to observe his behavior and interactions over a period of time. For this case, you don't need an SSL cert that is tied to a real world name, you need one that shows continuity over time. For example, knowing my real name would be of essentially no use in deciding whether or not to trust something I say in a post. Knowing that I am the same fuzzyfuzzyfungus who has posted in the past allows you to read my old posts and decide if I am reliable or not.

The solution to this need is not CAs in the classic sense, that verify identity then hand out a cert; but public repositories wherein people can deposit self-signed certs at a certain point in time and have that event on file, among a number of repositories, for anybody who asks. Then, if you go to my website, you can look at my cert and, rather then getting something useless like "certificate for foo-barr.org was issued to Mr. foo barr by Verisign", you can see "foo-barr.org has operated under the same entity's certificate for x years." From this, you could then judge the entity based on their last x years of activity.

The trouble with this notion is that it would require a subtler set of distinctions than the current setup, which people are, on the whole, already uselessly befuddled by. Oh well.

The question is about certificate validity

[Emperor Skull]

The question about if a certificate is self-signed or signed by a CA isn't really the issue, it's ensuring that end-users don't get certificate warnings in their browsers. An end-user should NEVER have to click through a certificate warning. That means the name in the certificate has to match the site, the certificate hasn't expired, and the certificate is trusted by the clients browser. If your application is internal to your organziation then you can distribute the certificates. (For example, we distribute our self-signed root cert to Windows machines through group policy.) When you are dealing with the Internet and customers, then there is no excuse to have an invalid or untrusted certificate.

Verifying SSL keys the way you verify SSH keys

[tepples]

This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise. What do you mean "control" of the certificate? [...] The private key is the part that means only the proper person can establish an SSL connection certified by that certificate. Incompetence that leaks the private key can happen faster than you might expect.

If you add an exception for a self-signed certificate then you basically have to trust that the first time you hit a site you aren't being hit by a man in the middle attack. It's a little bit harder for an attacker to make a man-in-the-middle attack if the owner of a self-signed certificate reads you the certificate's fingerprint over the phone, no?

Re:Verifying SSL keys the way you verify SSH keys

[Chuck Chunder]

It's a little bit harder for an attacker to make a man-in-the-middle attack if the owner of a self-signed certificate reads you the certificate's fingerprint over the phone, no?

Do you actually imagine that is a viable solution for a "web site"?

Re:Verifying SSL keys the way you verify SSH keys

[tepples]

It's a little bit harder for an attacker to make a man-in-the-middle attack if the owner of a self-signed certificate reads you the certificate's fingerprint over the phone, no? Do you actually imagine that is a viable solution for a "web site"? For the web site of a random online store with a merchant account, no. For the web site of a bank or a widely used payment processor such as PayPal, yes.

Re:Verifying SSL keys the way you verify SSH keys

[osu-neko]

For the web site of a random online store with a merchant account, no. For the web site of a bank or a widely used payment processor such as PayPal, yes.

No no, this is Slashdot. Your solution must either work perfectly in all possible situations, or it's useless. ;)

Re:Verifying SSL keys the way you verify SSH keys

[Chuck Chunder]

For the web site of a random online store with a merchant account, no. For the web site of a bank or a widely used payment processor such as PayPal, yes.

Do you really think the average person would ring such a phone number or understand what they are doing? They, by and large, would either be turned off by it or ignore it. Therefore it's not a viable solution.

And what's the advantage for a bank/paypal? They avoid paying a few hundred dollars a year for a certificate but have to pay people by the hour to answer the phone (a recorded message could not possibly hope to explain signature verification effectively to the average punter)? That isn't going to be a cost saving and trusting certificate authentication to people being paid minimum wage is hardly going to be a security enhancement.

Individual key verification may work well for ad-hoc individual to individual communications but is inefficient for frequent use. (Which is why PGP allows public keys to be signed and a trust matrix established).

Re:Verifying SSL keys the way you verify SSH keys

[Chuck Chunder]

No no, this is Slashdot. Your solution must either work perfectly in all possible situations, or it's useless. ;)

How about working better in any situation?

Do you really want to ring up Paypal to verify a certificate? Is the average internet user capable of understanding that process? Does you bank gain anything by saving a few hundred dollars on a certificate and then paying people to answer phone calls about self signed certificates? Is security enhanced by having some minimally paid customer service drones verifying certificates for customers?

In all cases, no.

Bravo, plus some info on Enigform

[buanzo]

Bravo, bravo!

http://maotest.buanzo.org/ (some stuff with OpenPGP for HTTP, secure session initiation, etc)

CACert.org

[Anonymous Coward]

Personally, I use CAcert certificates for all my personal stuff. It's a bit easier than creating one's own CA or doing one-off self signed certs.

Law

[Anonymous Coward]

The underlying reason for the use of a self-signed certificate in this case is probably due to legal issues. Because this "site" is distributing copyrighted material (without the expression permission of the copyright owner) this could be viewed (and in some areas is viewed) as a crime. This will mean any certificate issued for the "site" for this "purpose" would breach the Certificate Policy of the any issuing Certification Authority. This could make the Certification Authority liable for the actions of the site (they have vouched for the activities of the site, after all).

Bottom-line: No legitimate Trusted Third Party would vouch for a "site" that conducts "criminal activities". Imagine what would happen to their repuation.

Possibly advantage of a CA

[mpcooke3]

If a large number of people complain that a company is not who it claims to be or a certificate is compromised the CA can potentially blacklist the certificate.

I guess this is a potential advantage of a CA, even though they are generally pretty useless.

Man in the middle

[Spazmania]

Signed certificates provide exactly one additional protection versus no certificate at all: sessions so protected are not vulnerable to a man in the middle attack. With a self-signed certificate, someone in the middle can create a new self-signed certificate, decrypt and log your communications and then re-encrypt them with the site's real certificate. As the user, you won't know because it all looks the same to you.

That having been said, SSL with a self-signed certificate is MUCH more secure than no encryption at all.

Just provide the checksum for your certificate ...

[buchner.johannes]

ideally on your website

Under separate cover

[tepples]

The process for adding a trusted root authority in [IE 7 or Firefox 3] is not particularly user friendly. Really? In Firefox 2, the process was as follows:

1. User receives a certificate fingerprint under separate cover, such as mail or phone, along with the following instructions.
2. User visites SSL site and gets warning message.
3. User clicks show certificate.
4. User compares certificate's fingerprint to the fingerprint sent under separate cover.
5. User clicks "accept certificate permanently".

What part of this process significantly changed from Firefox 2 to Firefox 3?

Re:Under separate cover

[Ammin]

Firefox 3 will still give an error message if the certificate is not from a trusted authority. Believe me, I've been working with this issue for the last week and Firefox 3 has adopted a much stricter approach ala IE 7. It's probably a good thing, just creates more hoops when you're developing on test machines, etc.

Sometines it may be better

[setrops]

If someone you know is setting up a website for personal reasons and the use a self signed certificate. Would it not be better to accept the self signed certificate? If you do not accept the certificate CA the you will be constantly prompted to accept the certificate and if there is a change in the certificate or you are redirected you will never know.

Re:Just provide the checksum for your certificate

[Spazmania]

Anyone capable of implementing the man-in-the-middle attack that signed certificates protect you against is also capable of modifying you web pages in flight so that the checksum the user sees matches the certificate they created.

True Story

[BLKMGK]

While at DEFCON working the Wall of Sheep one year we discovered that someone had setup a WEB site on the network to bet on the outcomes of the hacking contest - they used a self signed SSL cert. Now some people, being paranoid on a VERY hostile network, turned down this certificate and promptly created\used the WEB site sans SSL - exposing their creds clear text. We promptly snarfed these and posted them on The Wall. 0wned!

All they had to do was accept the cert and they would have been protected. But I guess since seeing that pop-up was out of the ordinary and being on a network that was so nasty they thought they would play it safe and say NO, how stupid....

Re:True Story

[Anonymous Coward]

Any reason you absolutely must type "web" in all caps?

Re:True Story

[Burz]

All they had to do was accept the cert and they would have been protected. Only because neither you nor someone else had a MITM waiting for him. In general, the safe thing to do would be to not use the site until the cert's fingerprint could be verified with the operator in person or via secure email.

Re:True Story

[BLKMGK]

Excellent point! I hadn't thought about it from that standpoint but you're correct that they had no REAL way to know it wasn't a MITM offering the cert. However by turning down the cert *everyone* on the network got to see what they were doing! Verifying with the operator would indeed have been smartest!

Re:True Story

[Anonymous Coward]

WHich browser is it that falls back to HTTP when an HTTPS connection is terminated due to the SSL cert being rejected?

Re:True Story

[Burz]

Well, the browsers I'm used to will have you choose between "Cancel" in which case the browser won't connect, or "Continue" to accept the cert anyway.

You'd have to do more than turn down the cert. You'd have to manually go to the unsecured http: address.

Re:True Story

[Anonymous Coward]

Okay, so you set up a web site with the same IP address, create your own self-signed cert, proxy it to the real site. You have creds in clear text, too. Still PWND.

On a VERY hostile network, can't trust self-signed or clear text communication. About the only thing you can trust is CA signed certs, where you have a established trust with the CA.

Re:True Story

[BLKMGK]

Can't tell you exactly how they did it, only that we saw a request in cleartext and that when we attempted to goto the same URL to see WTF was going on we got hit with the 3rd party SSL cert. I believe we canceled that and still got the page but I may be mistaken, I know we got their data cleartext though :)

Re:True Story

[asdfghjklqwertyuiop]

All they had to do was accept the cert and they would have been protected.

And then all you'd have to do to 0wn them in that case is intercept the TCP connection from them to the web server and present a similar looking certificate with a key of your choosing.

Then all they'd have to do is accept the cert and they would have been protected.... right...

Re:True Story

[Carlos Laviola]

Now some people, being paranoid on a VERY hostile network, turned down this certificate and promptly created\used the WEB site sans SSL - exposing their creds clear text.

What? No seriously, what does this mean in English? That you got someone's passwords because there was a HTTP version of the HTTPS site?

Re:True Story

[BLKMGK]

Well familiar with MITM attacks thanks - been pointed out already as well. Denying the SSL cert meant they were vulnerable to everyone with NO protection, accepting one would have been the lesser of the two evils even ASSuming I had a MITM setup - which on the DEFCON network is actually pretty likely :)

Re:True Story

[BLKMGK]

In English... They were apparently presented with a cert (we were when we tried the site) but they apparently turned it down. Why apparently? Because we saw their password exchange in CLEAR TEXT. We posted it to the wall shortly thereafter. So yes it seems there was an HTTP version of the site waiting for them when they turned down SSL it seems.

We saw others access the site - their exchanges were encrypted SSL and not captured.

Re:True Story

[cbhacking]

In other words, the users made a reasonable decision (avoiding the use of an untrusted cert in a location where I'd be surprised if there wasn't *at least* one MITM program)... then turned around and made the worst rookie mistake on the whole net (sending sensitive data over a completely insecure connection).

Meh, if I was you, I'd have done exactly the same thing you did... except I'd have been the one running the MITM, and I'd have posted the data of anybody who accepted the untrusted cert as well. Might have used different colors to differentiate the overly trusting from the blatantly stupid.

Re:True Story

[BLKMGK]

Oh indeed that would have been fun! However on a switched network it might have been a bit difficult without the site owner's assistance. tipping over the switch to a hub mode could possibly have been done but that sort of garbage spewed onto an already heavily worked network would have been cause for the Goons to come hunting us with a big stick. We generally enjoy span port access to the switches these days which is nice but if we cause issues we'll be kicked off as fast or faster than the rest. Really we just look for the low hanging fruit and try not to screw up the network while collecting data. Even just going after clear text and easily decrypted passwords we get plenty of them every single year. We've even gotten hold of credit card transactions via vendors and POP creds for some of the Goons! Stuff happens but the SSL thing was pretty damned amusing and happened to be applicable here :-)

Mod parent DOWN, please

[Burz]

He is spreading misinformation. The Internet and its security mechanisms were never meant to verify real-world identity (whatever that means: photo, street address, SSN?) or good intentions. Yet SSL does, however, validate the site's Internet identity... it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name. As others here already pointed out, this prevents MITM attacks.

Thus, when you conduct critical business on the Internet, it is important to get the service's URL right from the horse's mouth. Otherwise a slightly-misspelled domain could amount to an attack of a different kind.

Self-signed certs are OK if you have a decent way to distribute the certs to others. For instance, if you can get the cert's fingerprint listed on various other sites... people can then check the fingerprint through alternate channels of the cert they downloaded and imported into their browser/client. Distributing in-person among trusted individuals also works.

OTOH, having a domain name mismatch would make me doubt whether the link could stand up to MITM attacks or if the cert I received wasn't a fake. Perhaps verifying the fingerprint is enough to satisfy most people, but for me it raises doubts about the site's technical ability.

Re:Mod parent DOWN, please

[Anonymous Coward]

What the moderation on the grandparent tells you that there are a lot of moderators who are pissed that certificates are so expensive. Nothing more, nothing less.

Re:Mod parent DOWN, please

[sjames]

it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name. As others here already pointed out, this prevents MITM attacks.

No, it doesn't! It ensures that the server that you are connected to has a cert with the name of the domain on it. It could have been signed by any of the many CAs in the browser's list. Perhaps the real site has another cert with that domain name on it signed by another CA, but you won't know that.

The system is only as believable as the least conscientious CA in the list.

Re:Mod parent DOWN, please

[WGR]

it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name Actually, it doesn't quite do that. It only assures that the server's reverse DNS lookup result is the same as the server name in the certificate. It does not authenticate IP addresses, nor whois informations, just that server names match reverse DNS lookup results. If someone can commandeer the reverse DNS servers, they can be SSL authenticated without actually controlling the true server.

Client -> MITM server -> actual site
             
                  \ /
actual certificate
                  / (pwned DNS server)
            certificate with IP address replaces by MITM server IP
client

The MITM server can use actual certificate because it only verifies server name (which points to MITM server, not true one), not true server IP address. If someone gets your DNS and reverse DNS server,they get you, but most domain's DNS servers use UDP with no security to return responses, so are easily spoffed with MITM attacks.

             

Re:Mod parent DOWN, please

[Burz]

That is a very dramatic claim. Can you provide good references that back it up?

As I understand it, the CA would also have to be spoofed along with DNS... but the would-be spoofer wouldn't have the CA's private key to make that possible.

Re:Mod parent DOWN, please

[WGR]

The point is that the MITM is using the ORIGINAL certificate. He has no need to spoof anything but the IP address sent and returned to the client. He presents the true certificate to the client, so no need to accept a self-signed cert. He is able to talk to the true server as if he were the client, since the server does not normally have a certificate for the client to verify.

What he is not able to do is decrypt the traffic for that first page, but if he has his own certificate, signed by a trusted CA, he can easily substitute this for every page after the sign in page and capture the rest of session, including things like requests for a password because of "session timeout".

Re:Just provide the checksum for your certificate

[buchner.johannes]

It was a joke.

its just the problem of key distribution

[Anonymous Coward]

First, keep in mind that we do not trust an end certificate, we trust the issuer.

Second, There is no requirement that the Common Name match (or be a suffix of) the system's DNS name (but there is the common usage).

Apart from the roots, a self-signed certificate is identical to a publicly-signed certificate.

So... the *SINGLE* issue is the key distribution problem: how do you verify the self-signed you received is indeed the self-signed you *should* have received?

For example, remember the "VerySign" certificate that used to be shipped with a famous package some years ago...

You are correct to point that out

[Burz]

However, that is why Https security has to stand on a 'tripod' from the users' point of view:

1) The lock icon appears in the address bar (while a picture of a lock on the page doesn't count).

2) The domain name in the address bar is spelled correctly (because the lock is saying that the cert 'matches' the domain).

3) No certificate warnings appear from your browser.

If any one of those 'legs' is missing, then assurance of link security falls down. Otherwise (barring your computer being infected/compromised, or having a massive bug) you can be sure the link is both solid and also not a phishing site.

Re:You are correct to point that out

[cbhacking]

Every now and then, a phishing site apparently gets issued a signed (by a trusted CA) certificate. If you can present a valid, trusted certificate fr the domain paypa|.com, the user will see all three of the things you describe above. Even if the cert is immediately revoked, most browsers don't (by default) check for certificate revocation on every connection.

Always and Never

[rdebath]

The public key of the self signed certificate should already exist in the browser's certificate store. If it doesn't the link is not secure until it is possible to prove that the certificate came from the entity you want to communicate with.

If the certificate is not already known the browser should say the link is insecure and probably switch back to using http.

A self signed certificate can and should be installed into the browser but only after you've manually validated it.

Once validated it may be more secure than a global CA issued certificate because there no certificate chain that may have been compromised. However, most users wouldn't know how to validate the certificate or even that they should.

Re:Always and Never

[Anonymous Coward]

You are basing this all on whether or not SSL is being used for authenticity in this case. Self-signed certs don't even have to be verified if you are only using them for encryption.

Re:Always and Never

[JSBiff]

Uhh, what exactly, is the point, of encryption when you can't verify the key? If you haven't verified the key, there is no guarantee that your data isn't being seen by a Man-In-The-Middle, so the encryption might not be doing anything useful for you at all.

Re:Always and Never

[gnasher719]

Uhh, what exactly, is the point, of encryption when you can't verify the key? If you haven't verified the key, there is no guarantee that your data isn't being seen by a Man-In-The-Middle, so the encryption might not be doing anything useful for you at all. With a self-certified certificate, the ones who can see your data are the receiver, and the Man-in-The-Middle. Without a certificate, the ones who can see your data are everybody and their dog. That makes some difference in how difficult it is to spy on you. With a self-certified certificate, spying on you is not impossible, but harder.

It gets worse when you are afraid of an attacker that doesn't target you specifically, but tries to target thousands of people. With self-certified certificate, spying on one person is difficult; spying on many is very, very hard. Without any encryption, spying on thousand persons is a lot, lot easier. It's like the difference between leaving your door wide open and having the door locked, with the key hidden under a stone.

In this case self-signed is the only solution

[Permutation Citizen]

When you sell any kind of hardware with an embeded web server for remote usage and administration. You want to allow SSL encryption, as the administration of the box requires a login you want to protect.

One thing you can't do, is to put your own private key corresponding to a certificate that identify you inside this box. It would be a nightmare to ensure it can't be retrieved, as anyone buying your product has a physical access to it.

So a self-signed certificate is the only solution, but your customers will have an ugly warning.
 

Self-signed certs are like ssh known hosts

[Junta]

They no longer have a trusted third party, so you should validate the SSL certificate as you would an ssh known_hosts entry. One remembered, it affords the same degree and type of protection as known_hosts. A very easy and direct comparison.

discouraging eavesdroppers without validating host

[akadruid]

In this case, the end user does not care who is publishing the material, only that nobody listens.

It's more like a random stranger has offered to send you money either in the bulletproof truck, or slung in the back of a pickup.

Confused?

[daveyboy79]

Isn't the idea of Location and Security independent from the certificates point of view?

What I mean is that even with a CA, the CA will simply issue a certificate to anyone who requests one and can prove they are from said location. A self-signed certificate OR a CA generated certificate need to be installed on the root of the server/web site so that any traffic coming to it will be encrypted using the keys held within. Whether it is self signed or CA generated, it won't affect the actual direction of the traffic or redirect traffic to a man-in-the-middle attack.

The problem appears to be that because there is a certificate on the web site, people will assume that it comes from a legitimate source (ie. Because https://scam.barclays-2339.ru/ has a https, it's gotta be Barclays Bank!) If anything, it's just breaking the ability to hide links behind text, so this link here Barclays Bank must display the link (ie. for example here [SCAM.barclays-2339.ru].

Infact, I've just realised, it's like the way slashdot has formatted my links here!!

Interesting

[Burz]

But I think you should remember that the warning dialog actually provides an opportunity for the user to import self-signed certificates.

Rather, if more sites simply made a habit of posting their cert's fingerprint elsewhere on and off site, then people could make the most effective use of self-signed certs with the current browser behavior in place.

I know

[Anonymous Coward]

I'm the first to notice: There is actually no link in the summary.

Verify Against A Known Cert?

[Anonymous Coward]

A lot of places use self-signed certs. I just wish there were an easy way for me to say "Yes. I verify that this is the correct hash of this certificate." so that I don't have to worry about CAs or accepting some place as a CA so that I can use their certs. Some programs do this, and others *always* throw up error flags on self-signed certs and/or mismatched domains.

I want more programs to allow me to say "Yes. I verify that this is the correct certificate even though it is self-signed, and even though there is a domain mismatch." Then I would feel better about some of the self-signed certs because I would know that everytime I get a cert from that location, the program will check it against the cert that I got in the past and accepted as the correct one.

I'm talking in general here, but one of my main beefs is w/ fetchmail. Fetchmail doesn't allow me to say "Yes, I know that mail.mydomain.com mismatches with a.lot.of.subdomains.here.dreamhost.com, but I want to accept this self-signed IMAP/POP certificate as the correct one for mail.mydomain.com. Verify all further SSL connections to mail.mydomain.com against this certificate."

Answer

[Burz]

The only ways to really tell with a self-signed cert is to 1) personally get a copy of the cert from the site's operators; or 2) lookup the site's fingerprint from an independent channel you trust and check it against the fingerprint your browser shows when you click on the lock icon.

Re:Answer

[Yvanhoe]

Which is what Verisign do. From what I understand, your browser (or even the OS ? not sure about that) comes with a certificate that allows you to create a secure channel with verisign which then will give you the key to authenticate the challenged server. So, Verisign verification, matches your #2 through a #1 channel.

Re:Answer

[Tony Hoyle]

No it doesn't work like that. Verisign issue a certificate that is signed with their private key. Their public key ships with the browser as 'trusted' so anything that verisign signs is automatically trusted in the same way.

The *only* thing a verisign certificate says is that the certificate owner paid verisign to sign it. It says absolutely nothing about the site itself. Phishing sites have used signed certificates as well.

Re:Answer

[Burz]

Phishing sites have used signed certificates as well. But their cert won't match the domain name that their intended victims are trying to access, so the browser will throw up a warning.

You pretty much have to ignore both the cert warnings or the domain spelling in order to be a phishing victim. That requires rank carelessness or ignorance on the users' part; In the latter case, it is important that users become educated about the issue by techies less cynical than yourself.

Re:Answer

[Dragonslicer]

But their cert won't match the domain name that their intended victims are trying to access Of course it will. If your site is www.exampIe.com, and your certificate is for www.exampIe.com, the browser won't complain. Why should it? The certificate matches the domain you're accessing.

Re:Answer

[Burz]

No, if they are trying to reach "example.com" and end up with "exampIe.com" in the address bar, then checking the spelling after the lock appears in the address bar will tell the user something is wrong.

Really, all you have to do is look for the lock, check domain spelling, and have no cert warnings to defeat phishing.

Re:Answer

[letxa2000]

GP: Phishing sites have used signed certificates as well.
You: But their cert won't match the domain name that their intended victims are trying to access, so the browser will throw up a warning.

Only if the phishers try to deviate requests for www.somebank.com to their new server and new certificate. But if they send out a phising email they probably don't interfere with the somebank.com, rather they just send users to www.s0mebank.com for which they DO have a valid certificate and the browser will NOT throw up a warning.

Re:Answer

[bonhomme_de_neige]

Of course it will. If your site is www.exampIe.com, and your certificate is for www.exampIe.com, the browser won't complain. Why should it? The certificate matches the domain you're accessing. If www.example.com is a major bank's website, and you contact Verisign to get a signed cert for www.examp1e.com (a blatant attempt to masquerade for said site), I think you might find they are not as willing to just hand it over as they would be for www.myhobbywebsite.com (which in no way resembles the domain name of any major banks).

Re:Answer

[osu-neko]

No, if they are trying to reach "example.com" and end up with "exampIe.com" in the address bar, then checking the spelling after the lock appears in the address bar will tell the user something is wrong.

Since you failed to change to a typewriter-style font above, the two quotes strings look completely and totally identical to me. Since they're both absolutely identical in appearance, just what method were you suggesting users use to "check the spelling"?

Re:Answer

[Burz]

They look dissimilar here, especially when the browser starts to load the page -- all characters are converted to lowercase. This occurs whether or not a site is found.

But you are right to point out that fonts themselves can present a security issue.

Re:Answer

[WGR]

But their cert won't match the domain name that their intended victims are trying to access, so the browser will throw up a warning. Actually, if a phisher is going to the trouble to get a signed certificate, it will also probably get itself a domain such as
mybank.co (from Columbia) instead of mybank.com and get a cert for that.
Are victims of phishing attacks going to know the difference?

Re:Answer

[Burz]

Are victims of phishing attacks going to know the difference? Better question: Are you going to remind the people you know to check the domain spelling?

A Nitpick

[value_added]

While the article does ask about web sites, the kids should know that SSL is not something whose use is exclusive to websites and web browsers.

The relevant Transport Layer Security Wiki article would be a good start.

SSL - PGP style?

[caluml]

Is there any work on SSL-type functionality, but based on a PGP web-of-trust rather than a top-down I-trust-the-CA-so-I-trust-any-certs-they-issue style?

Mozilla-Bug

[Anonymous Coward]

Where was that bug of mozilla and the so very free SSL Cert-CA?

It's the best choice

[Benson Arizona]

When a hacked link or poisoned DNS cache redirects your browser to a hacker's server for processing of your credit card details, you will be none the wiser because the hacker has purchased a certificate from . On the other hand, I will be warned by my browser because I have deleted all of the commercial root certificates. If I am satisfied with the credentials presented then I need only click once on "accept this certificate permanently" and will never see the message again. The point is that the only acceptable "trust authority" is me and once I am satisfied by the authenticity of the site then my browser may continue to communicate with it. I have no interest in whether or not the site has given money to a CA and certainly don't view this as a reason to "trust" it. Consider, for example, the links to "ads.doubleclick.net" that you are probably viewing while reading this. On encrypted pages those images come from a server that has a commercial certificate. I don't see those advertisements but you are irritated by on-line dating services and people who just want to be your friend whilst having your bandwidth reduced and download limit consumed by them.
The choice is yours, of course but I say "delete those root certificates now" - you know it makes sense.

Users of MS-Windows (whatever that is) should note that they need to retain a Microsoft certificate if they want to allow Microsoft Update to continue to automatically erase all of their device drivers and quarantine the one piece of really useful software that they run.

I'd always thought they had uses?

[Anonymous Coward]

I know I'm just a horrible gutless AC (For various reasons, hopefully someone can put that aside for now and get me a helpful reply?) but I'd always thought they had pretty obvious and useful applications.

In my case, main use is in having secure e-mail client-to-server, with a self-signed cert on the server end.

Yes the Thunderbird/Outlook/whatever warnings are annoying until you hack a way around them, but if you have a known IP you're connecting to and a self-signed cert how is this not providing useful and simple security? Or am I missing the point in a big way, does SSL not add any security to the connection?

I'm seriously quite interested as I'd always thought of it as a quite handy (And free!) security bonus.

visibility versus reality

[nimbius]

i tend to find it comes down to a matter of customer base. for example, my internal mailservers, wiki's, and webservers all use self-signed certificates, as by and large we just want an encrypted channel to pass credentials and email. public webservers, oracle transaction servers, and credit card processing pages however always have the shiniest and best VeriSign (C) certificates. it makes people feel good if their browser gives tacit approval of the safety of the online transaction at hand, and the identity of the institution involved. I've also been told by the legal department it is an unwavering mandate that we have certs from someone like VeriSign.

Bullshit.

[Chuck Chunder]

There's no need for a "man in the middle" attack, nor is there any need for you, as the consumer, to do anything differently. You're simply hosed. You may think that you're talking to secure-as-heck.com, but in reality, you're talking to hacker-boy-69, who has pwned secure-as-heck.com, and who is now gleefully collecting your information.

You can't just ignore man in the middle attacks because there are other potential attack vectors (an inside job or a compromised server). No one security measure is going to provide ultimate protection from all attack vectors, thus the need for layers of protection.

Certificates help protect against a certain set of attack vectors and have value because of it.

They are overly expensive, especially from some vendors and for wildcard certs, but ultimately cheaper and easier than other methods of verification (such as manually verifying self signed certs over some other mechanism).

self signed ok on intranet

[Anonymous Coward]

I think self signed SSL is ok in an intra net. It will still encrypt the connection and everyone in the company should know it is a intra net server. Maybe have a browser rule that ignores SSL warnings in the intranet zone.
Again this assumes the IT determine does not allow rogue webservers on the intranet and has control of the network.
I do not get the reasoning in the post for copyright reasons. I think it would be cost because a CA cert costs $$

Re:self signed ok on intranet

[speculatrix]

I created a certificate authority cert at work, imported it into web browsers and mail clients.

I then created a bunch of certs for internal web servers and mail servers, and it worked fine.

Then we bought a wildcard cert and I can use that everywhere now (where I can keep the certificate files secure), so the need to install our CA cert on all new computers is avoided, and everything "just works"

Quit being so cheap...

[Anonymous Coward]

I just bought an SSL cert for a site through godaddy.com for $26 for 2 years. The CA root authority backing this has 99% placement in browsers distributed in the last 2 years.

Pony up a few bucks and shut up...

virus/trojans with certificate authority

[speculatrix]

I've often wondered whether any viruses/trojans have tried to subvert the browser's list of certificate authorities... if they could add one without the user knowing, they could then hack the user's DNS or hosts file to divert the browser to their spoofed bank website without any security alerts being generated.

Man-in-the-middle attack possibility

[JSBiff]

It all comes down to, can you determine that you are using the same crypto key that the server is? The reason for signing certificates and the like is to try to detect when you are being hit with a man-in-the-middle attack. In a nutshell, that attack is when you try to open a connection to your 'known' IP address, say, 123.45.6.7. Even though you are connecting to a 'known' IP address of a server you trust, doesn't mean you can necessarily trust traffic from that IP address. Why not? Because the Internet works by passing data from router to router until your data gets to it's destination. Every router in between is an opportunity for malicious code on that router to re-write your packet, and you'd never know the difference, unless you have some way to *verify* that the packet is from the trusted server.

A crypto key, if you have the *correct* key, can verify for you that the data hasn't been tampered with. The problem is, however, that before you can begin encrypted communications, you must do an *unencrypted* key exchange, where the server gives you it's crypto key. Here's where the man-in-the-middle has an opportunity. If your traffic is going through my router, I can intercept the self-signed key from the server, and generate a new self-signed key with the same server name, etc in it, so that it *looks* like the self-signed key from your server, but which allows me to decrypt the communications between you and the server. My router then establishes a connection to the server using the *correct* key, and as data passes between you and the server, I unencrypt the data using the real key, then re-encrypt it using the 'fake' key. So, the data is encrypted between me and the server, and between me and you, but gets unencrypted in my router, giving me the opportunity to spy on your data, or even alter if if I want.

The point of a CA-signed certificate is to give slightly stronger verification that you are actually using the key that belongs to the server you are trying to connect to.

Yes, self-signed keys have some uses - in particular if you happen to know the real key's fingerprint (a fingerprint is a numeric or hex string which identifies a cryptographic key), so that you can verify yourself that you are using the correct key for SSL. If you don't happen to know the fingerprint, it's probably still fine to use self-signed certs on a LAN, where you control all the equipment, so don't have to worry so much about a man-in-the-middle (although, arguably, on a LAN you might not even need encryption).

So, in summary, yes, SSL adds security to the connection, but ONLY if you can verify that the correct SSL key for your server is being used, and not a different key that a hostile router has injected.

Read this book and then get back to me...

[certain death]

Hacking Exposed, Owning a Continent. One of the best hacks I use as a security pro. is owning companies PeopleSoft installs when they use self signed certs. I can setup a proxy, copy their self signed cert, and capture usernames and passwords ALL DAY LONG! I recently seen a article here on the dot about how insiders are less of a threat now-a-days than outsiders...completely FALSE!

it's okay if...

[ZonkerWilliam]

You maintain the CA and have it hardened and secured on the network. I wouldn't use it , let's say, if it was used on an e-commerce site. But typical in-house ssl vpn connections should be ok, as long as you follow what I said earlier.

Fingerprint validation

[JSBiff]

Correct me if I'm wrong, but I believe that all the major browsers allow you to view info about the certificate that was presented, including the key fingerprint. If you know enough of the fingerprint, you should be able to verify that it is the fingerprint of *your* self-signed key, and accept it, without having had to manually install the key into the browser.

Yes, a self-signed certificate is just a secure

[hal9000(jr)]

The answer to you question is that you can use a self-signed certificate anywhere you can use one signed by a CA, public or not. However, to ensure that you are always talking to the web server and not through a MITM, you must distribute the self-signed certificate or the certificate thumbprint (and then verify it!) through some trusted means.

Using a public CA like Verisign buys you is that since their public CA certificates are already distributed in browsers, any certificate issued by them should just work. Oh, and make sure the host name matches the common name.

Re:Yes, a self-signed certificate is just a secure

[Deadplant]

Mod parent up +10 insightful for providing an island of clue in a sea of cluelessness.

Re:Yes, a self-signed certificate is just a secure

[cbhacking]

Very nicely written. Two nitpicks, though:
1) The distribution is so your clients can always be sure they're talking to you, not to a MITM. (You changed the party referred to by "you" in that sentence.)
2) In case your private key ever gets compromised, you need a trusted revocation system (as well as a distribution one). This is another feature that CAs provide.

Simple.

[raddan]

Does the user trust the CA? That's all it boils down to.

A case for self-signed certificates

[wbean]

A self-signed certificate is useless if you want to prove your identity to other people. It is, however, useful if you simply want to offer encryption to people who already trust your identity. As an example, I use a self-signed certificate on my mail server. I'm not terribly worried about anyone spoofing my mail server but I do like to be able to encrypt my credentials when I log in. The self-signed certificate works fine in that case.

Self Signed

[pietromenna]

Well, from my point of view, the self signed certificates, would be a nice way to provide secure login/access to system like blogs or wikis for example, but not for banks that the user really need to verify the authenticity of the host. This is not provided by a self signed CA. But for non critical sites you can simple use the self signed to provide ENCRYPTATION between the two sides.

It looks like it's a pretty obvious answer ...

[Keyslapper]

When your money is on the line, it's just NOT OK to accept a self signed cert. Otherwise, it really just depends on what the risks are and how much due diligence you are willing to put up.

Why not just accept them, because it's less secure?
Well, yes and no.

It can be pretty much as secure as any "professional" cert, but the thing is that you have to do some due diligence. With a professionally signed cert, you only have to decide whether you trust the CA and their processes. It's the verification you have to do on your own if you trust a self signed cert.

For instance: I run a small server with about half a dozen family email accounts and secure webmail. Everything going in or out is encrypted, meaning if it's not SSH, HTTPS, IMAPS, it has to be HTTP, SMTP or DNS traffic or it's blocked. Now, for the HTTPS and IMAPS traffic, I use certs signed by my own self generated CA. I do it this way because you can write the CA up to expire in 20 years, and just sign the certs a year at a time - or shorter. I then convinced my family members that they could trust my CA because they didn't need to verify my identity.

Now, keep in mind, there's little more than some personal email at stake, which given the majority of what my mom sends me, is about 2 gigs of religious tearjerker stories, silly jokes, prank pics, and videos of what not to do when you <insert anything here>.

Now, I'd accept such a cert from pretty much anyone I could verify to some degree that coincides with the value of risk.

Would I accept this from my bank? No freakin' way. I want to know that my money is secure, and that the folks holding it aren't running a half-assed operation. I want it to be professional.
It is for this reason I think most of the argument here is redundant. Remember everyone, the question was "when is it OK?" not "how do they do that?" or "what does secure mean?".

Now, if you're putting personal information up on that site, you need to know that it's the right site. It is perfectly acceptable to ask a sysadmin to email you the public key, the one you'll get from the webserver anyway. You can then match that and go from there. Easy and painless.

Another option is to assume it's a bogus site at first and enter an incorrect password. Sometimes you'll see something you don't expect. Still, that's getting a little on the paranoid side if you're just trying to grab an ebook.

Bottom line, it's ok if you're comfortable with it. If not, then you have to decide it's not. The cert exists to assure you that you've got the right place, not the site admin.

No it's not safe

[rgviza]

Ok, yes the traffic will be encrypted, yes the communication is safe. However, this sets up users to accept *anyone's* cert for that site. If the dns is hijacked or something, and the users are redirected to an attacker's server, the users will already be used to just accepting any certificate and they may accept an attacker's certificate and log into a malicious site, not realizing that the site is counterfeit and being operated by malicous people who are collecting their logins or worse. The whole purpose of using signed certificates is so that you know the site owner is who they say they are because Verisign checked them out. This is a very "ghetto" way to do things and I'd personally not use the site, since I have no way to verify it's really their server on a day to day basis. This is especially important when expiration time rolls around since the users will have to accept a cert again. How do they know it's really the same site operator and not an attacker? The attacker could just add a notice to the site: "Our cert has expired, please accept the new one and add an exception.". The user (who's done this once already) will think nothing of accepting the new one regardless of who it really belongs to. While not dangerous from a technological point of view, it is dangerous from a social angle. This is the whole reason certificate authorities exist, so users can verify who the site owner is, hence the name *Veri* sign. The op should have summoned the power of google for this info. -Viz

Re:No it's not safe

[Deadplant]

I'd personally not use the site, since I have no way to verify it's really their server on a day to day basis. But you'd use their non-ssl site?

It's the lazy way

[Anonymous Coward]

It opens you up to a man-in-the-middle attack, but sometimes all you care about is that the traffic isn't going in the clear over random wifi connections.

The better way, but less lazy since there's another step, is to create a CA yourself and sign the cert with it's key. And provide a way for users to add that CA to their browser's list of trusted CAs, that way the man-in-middle attack can only happen at that one initial request and actual requests to the SSL site will work as if it was a commercially signed cert...

The Pirate Bay

[Anonymous Coward]

In case you all haven't figured it out...he is referring to The Pirate Bay...

Its just a goddamn encryption key

[unity100]

and since they are signing it themselves they probably can offer higher bit encryption, like going up to 1024. it would be even better than bought certificates. most of the ssl certs sites buy from CA's are generally 256 bit due to the price tag involved. so you may be safer with pirates with an unsigned ca.

CA's vs The Real World

[rwyoder]

In the real world, all identification used by individuals to prove who they are is issued by governments. How far would you get trying to prove your identity using ID from some self-appointed "identification authority". Why should the latter be trust-worthy in the electronic world? Especially from a company like VeriSign who are the same nimrods who foisted "SiteFinder" on us???

I'm reminded of a quote I once read: "A certificate authority will protect you from anyone from whom they won't take money." IIRC, it was made by Paul Vixie on the NANOG mailing list.

CAs are not trustworthy

[Deadplant]

Self signed certs are the only ones you can 'trust'.
You just have to go and verify the cert in person (or at least out of band) before using it for identity authentication on the Internet.

Anonymous Coward

[Anonymous Coward]

Can use in two-way SSL where the client certificates are signed by your self-signed CA and your webserver/reverse proxy verify the client certificate.

A technical discussion: self-signed vs CA signed

[czmax]

I'll avoid the pissing contest about the CA/certificate vendor business model and concentrate on the technical question asked.

A self-signed SSL certificate should not be used.

The reason for this is that the IETF RFC's that define certificate path validation [see RFC5280] do not specify how to validate an 'end-entity' self-signed certificate. Each browser vendor implements their own logic in this area and _even_ if one assume they all do something reasonable the differences could cause a support nightmare.

A better solution is for the web site to run their own CA. This is very easy and there are many free or mostly free CA products to choose from. Openssl for example would work fine. Distribution of a new root CA is something all the browser's and operating systems support and one has a hope of making that work correctly.

Of course, as others have noted, the "proper" distribution of a CA certificate is debatable. Getting your new CA certificate shipped with the browsers is of course the approach CA/certificate vendors use. It is probably best but cost prohibitive and of course inappropriate for this scenario. The web site is best off if they can widely distribute their CA certificate or distribute it using an existing certificate from a CA vendor (ha!).

Simply distributing it on their own web page puts them squarely into the 'ssh' model wherein the first time somebody connects they get the CA certificate and from ever on they shouldn't have to go through that process again (if they do have to do it again it is a sign of a possible mitm attack). This is a well recognized model and arguably the web browsers should include UI to help support it -- but they do not.

Which means the users are being expected to handle and understand these issues. At which point perhaps the customers would appreciate it if the web site vendor spent that small sum of money and just bought a certificate from an established CA.
 

Self-sign a CA certificate

[greed]

The way I handle this, at work and on my home server for friends, is to self-sign a certificate signing certificate. I can then give my users a way to download and verify that certificate separately from the web site.

Then, my web site presents a certificate signed with that signing certificate, just like you'd get from a regular CA. If you've loaded the certificate signing certificate into your browser or system certificate manager, then no more dialogues.

This has the additional advantage: I can issue client certificates and tell my server to accept all client certificates signed by my signing certificate. I'd need to get a signing certificate to do that with VeriSign or that lot, and that's getting seriously spendy.

But if all you're using https: for is data hiding, then it doesn't matter, does it?

Re:idiots not really

[Anonymous Coward]

The browser and the intended URL which I AM SURE is a SS page negotiate the connection when one clicks submit. NOT the page on which you entered the information.

The current page has nothing to do with the method of transmission. Only the intended URL counts.

If the intended URL is SS then the transmission is SS!

The example...

[tjstork]

The legitimate bank is https://www.commerceonline.com/

I create my own domain and get my own certificate for https://www.mybankofcommerce.com./ I then proceed to look like Commerce Bank.

The problem is that the CA does not enforce trademarks, it only enforces that you say you are who your domain is.

When certificate vendors claim they protect ID, they can't make that claim, because they don't have trademark control over DNS or a web site.

How about when

[neuromancer23]

When neither you nor your customers want to deal with annoying pop-up messages stating that you are not a ca.

Things are not as they appear

[Anonymous Coward]

Just because the form PAGE is not HTTPS doesn't mean the form PUT isn't HTTPS, i.e. a form that doesn't show the little lock icon might still be perfectly secure, but without looking at the page source you won't know about it.

And, ironically, vice versa. I.e. you can have a HTTPS form that actually uses unencrypted HTTP to submit its' data. Your browser is supposed to warn you when you submit an HTTP ("insecure") form and when you go from HTTPS to HTTP within the same site, but after the first couple of times almost everybody turns that warning off.

How's that for security comedy?

Re:Things are not as they appear

[Free the Cowards]

HTTP form submitting to HTTPS is not secure, because you can subvert the form page to capture or redirect your login info without tripping any alarms. All it does is save you from passive monitoring, which is certainly a big plus, but it's vulnerable to a MITM attack that a pure HTTPS setup will protect you against.

Re:Things are not as they appear

[Workaphobia]

Good point. It makes me wonder why on Earth the browsers don't support easy detection of this kind of flaw. So what if firefox has an option to alert me whenever I submit unencrypted information? I don't want a popup every time I google something. Why is there no checkbox for preventing the submission of unencrypted information from an encrypted page? Why is there no security padlock icon for form submit buttons?

Can someone please explain?

[maillemaker]

I'm a little confused on this certificate stuff.

It sounds like if I make a web site, but set it up to go through https instead of http, users will get an error that I have an unverified certificate?

Why is this?

Why can't I just enable encryption on my web site, without any attempt at proclaiming my identity, and just have the browser start communicating with my web site via an encrypted channel?

In my view the only way we are going to get all these net neutrality and FISA issues resolved is by making it too hard to randomly eavesdrop - and this is done by encrypting everything. Why is this so hard to do?

Re:Can someone please explain?

[AnyoneEB]

Because provides no protection against man-in-the-middle attacks, so someone who actually wants to read your communications would have little trouble doing so. Of course, there is the catch that they would have to actually be in the middle when the encryption keys are exchanged, and then actively re-encrypt each packet going each way (because the attack basically means the attacker acts as a proxy for the server to the client and as a proxy for the client to the server). This is obviously a lot more work than dumping traffic onto a disk with some filtering for review later, which is already a rather daunting task with the amount of traffic on the internet.

That said, I agree: there should be some way to encrypt HTTP sessions with a self-signed cert (self-signed means that the user can know that they are accessing the same server they did las t time) and no warning: it just should not display the same lock icon because it does not offer the same level of security.

Things are not as they appear

[jurgen]

Just because the form PAGE is not HTTPS doesn't mean the form PUT isn't HTTPS, i.e. a form that doesn't show the little lock icon might still be perfectly secure, but without looking at the page source you won't know about it.

And, ironically, vice versa. I.e. you can have a HTTPS form that actually uses unencrypted HTTP to submit its' data. Your browser is supposed to warn you when you submit an HTTP ("insecure") form and when you go from HTTPS to HTTP within the same site, but after the first couple of times almost everybody turns that warning off.

How's that for security comedy?

(Duped because I neglected to sign in the first time)

StartSSL free certificates

[Matthieu Araman]

There's no reason to continue to use self-certificates today as you can easily get your certificate signed for free by http://startssl.org/
Their certificate authority is included by default with Firefox (you can add it manually with IE)
You can get a certificate recognized by default by the majority of browsers for a few bucks anyway.

Just make sure you have OSCP checking turned on on your browser (because it's so easy to sign a certificate that it has to be revocable easily)

Please also stop to use pre-computed certificates (ie localhost with a private key on a cdrom that everybody can get...) or reuse the same on different servers (in some cases, Firefox 3 now refuses to load them...)

Who is more trust-worthy?

[retsamxaw]

In the case of a local or regional e-commerce website, for instance, the company offering the e-commerce is more well-known and trusted by their customer base than any 3rd party entity could or would ever be.

I would argue that these companies should be able to self-sign their certs without a big RED screen or a warning in the browser.

Some Hong Kong post office is surely no more credible and authoritative than the regional chain of stores wishing to sell their wares to customers online.

I believe browsers should have an easy way of determining when and how the certs were created. An IP address stamp would be as much of a seal of authenticity as anything from Thawte, Verisign or GeoTrust.

Almost everyone in our region knows our company, for instance, but they have no clue what the heck Verisign does.

Self Signed Certifiates are more then enough

[Anonymous Coward]

In most cased self signed certificates are enough. In my line of work (communications software) customers generate a self signed cert and exchange with their customer(s). The certificates are compared by finger print, serial number and validity periods. If any of these do not match the communications are not accepted. A third party CA like Verisign doesn't ensure much but does make it harder for someone to create a duplicate certificate with the same serial number and information. For most secure communications like AS2 this is best because no one in the middle just direct communications between the two parties.

Info not in hands of CA

[alien51]

and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA CA has no access to the resources secured. You only give them your public key, which they sign to create the public key cert. Your private key stays private.

http://en.wikipedia.org/wiki/Certificate_signing_request/

Registries

[gmurray]

So much would be solved if we just had a trusted registry, to say, associate a certificate with a domain name, or an ip with a domain name, in a way that would be VERY HARD to spoof. I guess its a failure of DNS (big surprise). Now, if we just had some domain resolution servers that we could trust the identity and data of, then we could at least push the trust problem back further. The internet needs to be simple for consumers to use it properly (i.e. not neglect the s off the http when logging into their email or banking site). So could we simplify and just worry about the problem of how www.amazon.com resolves to some IP address and some public cert? If we have a trusted registry we don't need to worry about these trust chains any more, and it would solve a lot of the problems we have with DNS too, no?

Re:Registries

[gujo-odori]

Most of that is covered by DNSSEC, as outlined in RFCs 4033, 4034, 4035, 4310, 4641, 5155.

IIRC it doesn't have any hooks for any sort of CA infrastructure, but given all that there is in DNSSEC, it wouldn't be hard to add it.

The problem is that DNSSEC is even farther from actual widespread real world use than is IPV6, for reasons ranging from conflict between various stakeholders to "real" problems like getting it deployed on all the various name servers in the world, getting them compatible with each other, and backward compatible with plain old DNS. There are some very poorly implemented DNS servers out there, and they are very likely to only get worse when a more complex system, such as DNSSEC, gets involved.

For more on DNSSEC, see http://www.dnssec.net/ or check the Wikipedia entry.

Re:Registries

[gmurray]

hmmm... yeah, I suspected there would be some spec for this, but I hadn't checked into it. Thanks for the info.

Yeah, I could see why there might be rollout and adoption problems though.

Mostly I was just lamenting some of the inadequecies of the internet. Especially ones that seem hard to combat without further bootstrapping by governence bodies.

Simple Solution

[tj111]

My bank has a rather ingenious and simple way of preventing this. They put the username screen on one page, and after you submit it, you get redirected to a page that shows a custom "image" you previously selected from a list of like 1000 along with a custom "personal greeting". Then, right above the password prompt, they have this:

Welcome (me)
Your last successful login was on Monday, June 23rd at 11:54 AM.
Your last unsuccessful login was on Tuesday, March 18th at 7:37 AM.
The browser you are using is nicknamed Work LaptopXP and was identified by a cookie.

Do the picture and personal greeting match what you selected during the security enrollment process? If not, please contact us before entering your password.

I'm always impressed by the simple solutions people can come up with to these relatively complex problems.

create your own Certificate Authority

[Anonymous Coward]

If you are in the IT department of a small- to medium-sized company or department, it may be worth setting up your own CA.

When you image new machines (regardless of OS), you can install the CA's public PEM file, and so user's won't get prompt. Besides web sites, you can also use things like EAP-TLS for WiFi which greatly improves security.

There's a bit of overhead, but with something like TinyCA it makes things fairly painless.

They are half right, but so screwed up.

[Anonymous Coward]

"Their defense is that it is just as secure as one signed by a commercial CA;" From a cryptographic sense, they are only partly correct. The session data is secure from causal eavesdropping - but they no longer have protection from the "man-in-the-middle" attacks, since their certificate could be forged.

"the staff do not want to have their personal information in the hands of a CA". But I guess it's okay for a domain registrar to have it... WTF?

It's odd, since they use a self-signed certificate to deliver their copyrighted data they are trying to protect. It's not giving the users a false sense of security - it's give THEM a false sense of security.

Of course, if you're going to do a self-signed cert, at LEAST have it match your domain. Not doing that is stupid.

I have my own CA set up for various internal stuff, so any cert either has to be trusted by my CA as well. This way, I can sign my own stuff, but keep the CA protected to prevent cert forgery.

Thanks, another question...

[maillemaker]

Because provides no protection against man-in-the-middle attacks, so someone who actually wants to read your communications would have little trouble doing so. Of course, there is the catch that they would have to actually be in the middle when the encryption keys are exchanged, and then actively re-encrypt each packet going each way (because the attack basically means the attacker acts as a proxy for the server to the client and as a proxy for the client to the server). This is obviously a lot more work than dumping traffic onto a disk with some filtering for review later, which is already a rather daunting task with the amount of traffic on the internet.

OK, so what you are saying is that it does no good to encrypt end-to-end communications if someone in the middle also was in the middle when the keys were exchanged.

So I have a question (actually two):

1) I thought with public key encryption you only needed public keys available so there was no danger of such MITM attacks? Doesn't SSL use public key encryption?

2) How does a certificate prevent a MITM attack during the key exchange process?

Thanks.

Re:Thanks, another question...

[AnyoneEB]

I am not expert on cryptography. If you want a full picture, I recommend reading Wikipedia. Not that it was necessarily written by experts either, but at least it is edited and has an awful lot of information and links. Some good starting points would probably be Public-key cryptography, Digital signature, Man-in-the-middle attack, Transport Layer Security.

That said, I will answer your questions.

1. Yes, you need to have the public keys. A MITM attack involves lying about what the public keys are because the browser has to get them from the HTTPS server. Which brings us to question 2.

2. The certificate is a digital signature of the server's public key signed by some trusted agency (ex. Verisign). Verisign's public key is distributed with your browser so your browser is able to verify the signature. Of course, your browser was probably downloaded via an unencrypted HTTP connection, so that could have been MITM'd in theory.

Re:Thanks, another question...

[Ernesto Alvarez]

I'll answer that.

Public key encryption is susceptible to man in the middle attacks when using an anonymous key exchange. Since Alice does not know who is she talking to, she could be talking to Bob (as expected) or Trudy (an impostor). It is important that Trudy can ADD/DELETE/CHANGE the messages that go by. If Trudy is not changing anything, eventually Alice and Bob will get a common key and Trudy is screwed.

When Alice makes an anonymous key exchange, if she does it with Bob, then everything is fine, Trudy cannot look into the channel. The problem is that Alice might have negociated a key exchange with Trudy. She really does not know whether she is talking to Bob or Trudy (and if Trudy is a smart girl, she'll do the same with Bob so Alice and Bob both speak via Trudy instead of directly).

Now, let's see a TLS-like negotiation from Alice's side (Bob being the server).

Participants: Alice, The other side (TOS, Bob in theory)

Act one: signed by a bogus CA (that Alice does not recognize)

TOS: Here's my certificate. You'll see it says I'm Bob.
Alice: Yes, so it does. But I do not trust what scammers inc. says. You're not Bob!
(Alice hangs up)

Act two: Trudy tries to use Bob's certificate without the key

TOS: Here's my certificate. You'll see it says I'm Bob.
Alice: Indeed you are! Here is my KEX.
TOS: Here's my KEX
Alice: Great, we now have a common key! Now, could you sign a hash of it with Bob's key?
TOS: ummmmm, sorry I left the key in my other pants........
Alice: You're not Bob, you just took his certificate!
(Alice hangs up)

Act three: Trudy get a certificate from the CA

TOS: Here's my certificate. You'll see it says I'm B0b.
Alice: B0b, with a zero? Sorry, you're not the person I wanted to talk to.
(Alice hangs up)

Act four: the real McBOB

TOS: Here's my certificate. You'll see it says I'm Bob.
Alice: Indeed you are! Here is my KEX.
TOS: Here's my KEX
Alice: Great, we now have a common key (K)! Now, could you sign a hash of it with Bob's key?
TOS: Sure, here's the signature.

Alice verifies it's a signature of H(K), so she knows whoever owns the certificate knows K.
Alice verified the name in the certificate, so she know someone called "Bob" owns the key used to sign K above.
Alice verified that the signature belongs to an authority she trusts, so she knows that nobody messed with the certificate after it was issued.
Alice knows the CA to be trustworthy enough to check that the person claiming to be Bob is really Bob before signing the certificate.

Now, your questions:

1) I thought with public key encryption you only needed public keys available so there was no danger of such MITM attacks? Doesn't SSL use public key encryption?

There are anonymous methods for key exchange, if you use them with an impostor, you will not know and a smart impostor can then hook you to your real partner, allowing him to observe the contents of your communication.
Alternatively, he can just substitute your partner's key for his.
If the attacker is passive, there's nothing he can do and he will be thwarted.

2) How does a certificate prevent a MITM attack during the key exchange process?

By forcing the partner to prove his identity signing a derivative of the key exchange, or the messages that form the key exchange. All of this, provided the certificate is the real thing and not a forgery made by the attacker. That's why it is important to have a CA.
When you use a self signed certificate, you're basically doing act one. Of course if you got the real certificate (be it because your partner gave it to you or you just accepted it once and got lucky), you're back at act four (just like what happens with ssh keys).

Implement RFC5081 and use OpenPGP keys instead

[Fastolfe]

TLS doesn't have to use only X.509 with trusted roots. Get browsers and servers to implement RFC5081 and you can use OpenPGP keys instead. Take advantage of that web of trust.

Bad Guys can buy certificates

[PeterJFraser]

There are many many more small companies then there are large. Anyone can buy a certificate. If I wanted an extended certificate and I was going to carry out major fraud I would buy a small bankrupt company, create a web site under an ambiguous name then buy the extended certificate.

Furthermore if you need to buy something weird, the company that sells it is probably unknown to you. The only real check is to google their name and see if there are complaints. A CA signed certificate is no guarantee that they are good guys.

Bad guys have broken into sites that have certificates, and used those sites for their own purposes.

CA signed Certificates are also expensive.

I don't see how a CA signed certificate for a small company lowers fraud. Small companies are being forced to buy them because of the scares the browsers and other software generate.

CAs are "trusted" by the browser

[Anonymous Coward]

Certainly you can import the generated CA certificate into the browser and avoid the alarmist messages, but it certainly would be nice if the browser vendors would provide a way to register your CA so that it is included in the "trusted" list distributed with their browser. Thus avoiding the hassle of distributing the CA cert. Of course this introduces the difficulty of keeping the trusted CA list up to date on the browser, and the overhead of the registration process on the browser vendor.

RTFWP or just search ... PLEASE!

[OldHawk777]

Applied Security Technology will always meet the expectations of experience.

http://en.wikipedia.org/wiki/Pretty_Good_Privacy
http://en.wikipedia.org/wiki/OpenPGP#OpenPGP
http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Certificate_authority
http://en.wikipedia.org/wiki/Philip_Zimmermann
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail
http://en.wikipedia.org/wiki/Hardware_token
http://en.wikipedia.org/wiki/Biometric_authentication

https://www2.sans.org/reading_room/
http://www.giac.org/certified_professionals/practicals/gsec/4993.php
http://www.giac.org/certified_professionals/
http://www.linkmatrix.de/index.php?education=home
http://www.linkmatrix.de/tutorials.php?q=PGP

Those that can DO, read. Those who can read, but not DO, preach.
Readers, fakers, and test-takers always manage to fail.
Hands-On experience and continuous-learners always work for tale (or is that rep).

To many PGP/PKI/CA/TSL... comments are cross-BS technology application comments. Only in politics does mixed pieces of BS function properly or as expected.

In technology as in science it either does, or it don't do. There is working properly or working poorly (with a problem) until troubleshot and fixed. If it never worked or ain't working at all (cannot be made to function fully and consistently as expected) then someone fycked-up bad (miss-applied technology application) perhaps the brown-nose wannabe manager that can only read made a decision.

Let's use SSL EVERYWHERE

[yabos]

There are a few companies starting up that are creating software to spy on the ISP's customers. The ISP has to install this box into their data center and it collects data for every subscriber to build a profile. This profile is based on your browsing habits. The companies inject ads into your HTML page to spam you. The ISP gets paid by the companies for this. You are basically getting sold out by your ISP to be spied on by a 3rd party company.

One of these companies is http://www.phorm.com/.
SSL would completely block this. If every website, or at least a large percentage of them, used SSL, even if it was just a domain verified one from a CA so the browsers won't complain, these companies would be out of business before they started. There are large ISPs in the U.K. that are rolling this out already. There are also some ISPs in the USA that are beginning trial installations of this hardware.

Free CA

[Anomalyst]

http://www.cacert.org/
Discussed on /. http://slashdot.org/yro/04/07/02/0116236.shtml?tid=126&tid=158&tid=172&tid=95&tid=99

Acceptable, but with some risks

[Anonymous Coward]

If you, the user, can trust the site handing you the certificate to be the one as issued by the owner of the site and not modified by anyone else, then this is perfectly acceptable and is as secure as any certificate provided by any CA.

Now the issue here is that if the certificate has been modified during transit, then your security has been breached. This is something solved with CA signed certificates.

I just tested https://www.cacert.org/

[tepples]

Firefox 3 will still give an error message if the certificate is not from a trusted authority. I just tested https://www.cacert.org/ in Firefox 3 (build 2008052906), and it gives "Error code: sec_error_unknown_issuer". The procedure to add a self-signed certificate to Firefox 3 is similar to that in Firefox 2, just with different names on the buttons:

1. Click "Or you can add an exception..."
2. Click "Add Exception..."
3. Click "Get Certificate".
4. Click "View...".
5. Compare the fingerprints.
6. Click "Close".
7. Click "Confirm Security Exception".

Re:I just tested https://www.cacert.org/

[Anonymous Coward]

Oops, I assumed Firefox 3 was trying to make itself as rigid as IE 7 on Vista, since it was rejecting my keytool DSA signed certs, just like IE7. I stand corrected, it's still possible to add exceptions for non-root authorities in Firefox 3.

"that vulnerability is purely theoretical!"

[Anonymous Coward]

Can you cite any examples of a case where a certificate has been subverted in this way? Ah, you are of the "it doesn't matter if it CAN happen if it hasn't happened YET" persuasion. I can help you out here! There is a gentleman in my office who is not me (yeah, that's obvious, I understand). I have a cert issued by Verisign to me. Dave is not authorized by Verisign to use this cert. I am now handing Dave a copy on a USB stick. It is 14:05 2008-06-25 EST. Any more objections?

What about when you have an account/password?

[Rob Y.]

For cases where you're signing on to a system that has its own account/password validation, is it always enough to just use SSL for encryption only.

At that point are cetrificates even necessary, let alone ones signed by a 3rd party?

Re:What about when you have an account/password?

[Brian Gordon]

Well cert signing is important in most cases. Yes it's good for only encryption (though some crazies say otherwise) but the encryption is only as good as the private key that signed the SSL cert. So if the cert is signed by VeriSign or Thawte, you know the private key is like 80 megabytes long and is kept locked in a dedicated vault. Of course the encryption is also only as good as the cert itself, so you also have to trust the site not to lose it, but that's a much easier call than trying to research the CA.

Not really

[InvisiBill]

Don't signed certs also protect against phishing? When you go to your bank website, their cert is signed by a CA. If a phishing website is trying to trick you into giving them your username, they won't be able to have an SSL website that has the CA signed cert, which should be a red flag to a user that something is not right.

Not really. A phishing site could get its own SSL cert for whatever domain it's using. For example, a bad guy could get a cert for paypa1.com and https://paypa1.com/ would work just fine with a proper secure connection.

The idea is that Verisign or whatever CA granted the certificate should have checked them out, and only give them a cert if they're "good". However, their idea of "good" is completely up to them. You're trusting that whatever they say is good, is good to you also. But what if my name is Bob Paypa and I want to have an SSL cert for my personal domain, paypa1.com? I would hope Verisign wouldn't allow an obvious phisher to get an SSL cert for paypa1.com, but I also think they shouldn't flat-out reject SSL cert requests just because the domain name resembles another business' name.

Personally, I've never trusted the CA verification system. I see an SSL cert as something that guarantees my connection to that server is encrypted, nothing else. As others have said, if you trust a server enough to connect to it, then you might as well trust a self-signed cert from that server. Would I give them all my bank account info just because they have a cert? No. Would I do regular website stuff via HTTPS using their self-signed cert? Sure.

What SSL can and can't do

[Beryllium Sphere(tm)]

Security is analog, not digital.

Someone else could be in control of the certificate, but they would have to jump over the hurdle of compromising the confidentiality of a private key. Not impossible, but at least there are known defenses.

SSL replaces the insoluble problem of proving identity over HTTP by the multiple problems of
o Appropriate diligence by the CA
o Homophones and lookalike names [Search for "Mountain America Credit Union"]
o Good faith conduct by the CA (*)
o Protection of the CA's root signing key
o Due diligence by the browser vendor in setting up the list of trusted root certs
o Protecting the integrity of the list of trusted root certs on the client machine (**)
o Alertness by the end user
o Appropriate decision-making by the end user

That's just the short list I can come up with in the time it takes to write a Slashdot post. But even with all that, SSL identity verification is still better than nothing.

Isn't security fun?

(*) Bruce Schneier and someone from Verisign once worked out how much it would cost to compromise their master signing key. They figured that organized crime could take over the company in a leveraged buyout for someone in the low eight figures.
(**) It's terrifyingly easy to add a new trusted cert, and at least one piece of "marketing research" software installs its own cert and does a man-in-the-middle on SSL transactions.

Revocation is a scandal

[Beryllium Sphere(tm)]

Would you know that the certificate had been revoked?

Last time I looked, one popular browser didn't even check for certificate revocation by default, and in the one I'm using now I can't even find the configuration setting to control that.

Flaw in the CA-only model?

[argent]

Now the issue here is that if the certificate has been modified during transit, then your security has been breached. This is something solved with CA signed certificates.

It's also solved by having the browser install the unsigned certificate, which would allow it to go "OK, you're accessing this website through the same certificate as last time, nothing to see here", or to go "DANGER DANGER, the unsigned certificate for this site has changed!"

This is what SSH does with keyfiles, why don't browsers do this with certificates?

Because the certificate authority says they're not supposed to?

Or because nobody's thought of this obvious improvement?

Re:Flaw in the CA-only model?

[smclean]

For the record, I once said the same thing in a slashdot comment as well.

I don't know why browsers don't do it.

Re:Flaw in the CA-only model?

[argent]

I've been asking this since I first heard about the SSL certificate model, let alone saw it in action.

I've yet to see a good explanation.

Works for me

[psydeshow]

Self-signed certificates work great, provided you require users to install your CA certificate as one of the trusted certs in their browser.

We make our CA certificate available at a simple url (https://www.example.org/ca/) that uses a commercial certificate signed by a "real" CA, and provides an explanation and instructions on how to install our cert. Installation is straightforward in IE and Firefox, a little trickier in Safari.

Once our CA certificate is in the browser's trusted list, all of the other certs are trusted as well. The only thing to watch out for at that point is name mismatch issues caused by domain aliases and the like.

We considered publishing our certificate thumbprints, too, but that just seemed too paranoid.

trust? Pirate?

[shadowrat]

I assume the site in question is the pirate bay. It all boils down to how much trust you want to put in someone who calls themself a pirate.

Verifying the key out of band

[Beryllium Sphere(tm)]

>personally verified key signatures face-to-face.

Over the phone is probably adequate. You already know your bank's phone number. Incidents of phone numbers being rerouted are rare, though there are rumors of escort services in Las Vegas redirecting traffic meant for their competitors, and Florida's probation department once had their phone number remapped to a phone sex service in New York.

Over the phone, you'd just have the website operator read you the thumbprint for their cert. You could check it against the value shown in your browser.

Someone more mischievous than me should call up a bank and say "I'd like to verify the SHA1 hash of your X.509 certificate" and report on the results.

A realistic compromise is to note the thumbprint the first time you visit a site, hope it wasn't taken over at that instant, and then make sure it's the same next month when you visit again.

MITM?

[Anonymous Coward]

Oh, I see. Thanks Michael...

I'm Starting With The Man In
The Mirror
I'm Asking Him To Change
His Ways
And No Message Could Have
Been Any Clearer
If You Wanna Make The World
A Better Place
(If You Wanna Make The
World A Better Place)
Take A Look At Yourself, And
Then Make A Change
(Take A Look At Yourself, And
Then Make A Change)
(Na Na Na, Na Na Na, Na Na,
Na Nah)

I had this very issue at work this week

[Anonymous Coward]

At work we are setting up an internal only application with our internal DNS structure.

We don't have an internal CA and neither does our parent company, so if we need a certificate, we typically purchase certs from Thawte or Verisign.

However in this case our company doesn't have a valid domain structure internally, so purchasing a digital certificate would be redundant. I told them to setup a self signed certificate.

Yes it does encourage bad user behaviour and goes against best practise but given that I've seen far too many internal websites get setup without digital certificates, I felt it was the lesser of two evils.

Sometimes you just have to be pragmatic with your approach to security otherwise people will often take the easy way out and do nothing.

PS: Digital certificates provide two things:
1) Encryption: first and foremost
2) Authentication: It certifies the host is who it says it is.

2) is only useful if the certificate is issued from a trusted source.

Wanna co-author the article?

[ODBOL]

Dear Mr. Znork,

Your post is nearly unique in being short, to the point, totally on target, free of extraneous noise.

I wanted to contact you individually, but didn't see how to do it through your slashdot ID, hence this posted reply.

It appears to me (and to a number of other people who have a bit of reputation in security, which I don't), that self-signed records should be the starting point for "identity" on the network.

"For most purposes it's sufficient to know I'm talking to the same guy I was last time."

You have expressed probably the most important observation in the whole area. Furthermore, without the ability to know that all messages in a conversation come from the same agent, you can't accomplish anything else. And self signature is much easier than chain o' trust. Ergo, identity on the network should be founded on a system of self-signed records, with add-on services as they prove worth the trouble. (Roughly as delivery is founded on best-effort IP, with TCP, ..., HTTP as add-ons.)

I was working on this point some years ago, when I got permanently sick. I am unable to finish a publication without a co-author. On the outside chance that you want to do it, please write.

I think that the essential service is a free (OK, maybe just very cheap, but I bet it turns out free) server for self-signed associations of public keys with addresses (presumably, mostly IP numbers). The sponsor of the server should verify nothing about those who post records, and should ostentatiously deny all responsibility for their identities.

Almost all of the functionality is already provided by DNS implementations, where the domain names contain hashes of public keys. Google could provide the service next week (yes, I've contacted my buddies at Google, but they haven't bit on the hook).

To preview my ideas, you can check out

1. Pages 187-215 in the lecture slides with notes for a course that I cooked up a few years ago:

http://people.cs.uchicago.edu/~odonnell/Teacher/Courses/Strategic_Internet/Slides/

(That's at the end, up to but not including the last two pages in case your viewer numbers differently from mine.)

2. a horribly messed up page in progress:

http://people.cs.uchicago.edu/~odonnell/Citizen/Network_Identifiers/

3. A published article: "A Proposal to Separate Handles from Names on the Internet." Communications of the Association for Computing Machinery, 48(12):78-83, December 2005. Slightly longer version:

http://xxx.lanl.gov/abs/cs.NI/0302017

4. An Internet Draft:

http://xxx.lanl.gov/abs/cs.NI/0301011

2-4 describe the application of the same service to provide non-mnemonic free domain names/handles that won't be fought over in court and stolen. During the long wait for the article to appear in CACM, I realized that I should think of it first as Public-Key Infrastructure, with the handle function as a side benefit.

Cheerio,

Mike O'Donnell
michael_odonnell at acm.org

Who really "assume[s] liability"?

[ODBOL]

The guy who shows up in the truck (to borrow from the analogy) will have his cert, which is signed by the bank, which is signed by a CA, which is signed by a root CA. All of the people in that chain assume liability.

I have seen the assertion that CAs "assume liability" many times, but I have never seen a demonstration that they actually do. Neither a case where a CA provided relief to someone who relied on a certificate, nor the language in which a CA expresses the assumption of liability. I would very much like to see someone post an authoritative description of the actual assumption of liability by an actual CA (followed by an analysis from a competent lawyer).

I have no proof that CAs, such as Verisign, fail to back up their certificates, but all of my experience in related areas makes me assume that they do not. I have very explicit experience with agencies that provide credit reports, and I know definitely that they take no responsibility for the correctness of the reports. I think that the right default assumption for CAs is that they similarly dodge responsibility, until someone presents the evidence that they bear it.

Mike O'Donnell

Sometimes, usually

[bigtangringo]

If you know that you're talking to the proper site, which is verifiable via the key's fingerprint, you can accept that certificate permanently. From that point on, it's as good as a CA signed certificate.

However, if you get a bad certificate the first time around you're hosed.

That said, usually, you'll be fine.

Key Usage and Root Certificates

[Jaborandy]

When you add a self-signed cert, you usually add it to the root store. And if it's generated as a default self-signed cert, it probably thinks it's good for ALL USAGES. If you accept this cert for your little site-that-can't-afford-Verisign, you are opening yourself up to a world of hurt.

Not only can they man-in-the-middle you to any SSL web site (including your bank), but they can sign code claiming it to be from someone else, they can sign ActiveX controls, they can forge email to you with a forged S/MIME signature, etc. It's a huge risk.

I have and will continue to accept self-signed certs when the situation calls for it, but I also set the "Certificate Purposes" to a stripped down list. In this scenario, Server Authentication is all you need to allow. If the web site owner is not malicious, ask them to issue the self-signed cert with only that one use enabled, and match it to the name of the site/domain, and make it not a CA. Then they can still protect the communication channel, but they can't do anything else to you. Better yet, get them to set up a CA that can issue these certs, and get users to install that CA cert, enabled for only Server Auth.

--Jaborandy

oops

[Ernesto Alvarez]

I screwed up the rfc number.
It's 4346: "The Transport Layer Security (TLS) Protocol Version 1.1"

If you already have trust, and want encryption.

[IsaacSchlueter]

SSL is for two things: 1. Encrypting the data going back and forth between user and sever. 2. Proving that the server is who they say they are. #2 is inherently flawed, and really gives you nothing anyhow, as hundreds of comments before mine have pointed out. #1 is useful, and the lack of a lock icon doesn't change a thing. If you already trust the domain, then go ahead and accept the cert. I use SSL on servers that I run all the time, and don't bother to get a CA to sign the certs, since I trust myself to be who I say I am :) Just don't enter your bank info or email credentials unless you really really trust them!

Cases where Self Signed Certs are OK.

[Digital_Quartz]

However, self signed certs are useful when you have some means of secure distribution.

For example, I have a webmail client running on my server at home so I can read my mail while I'm at work (my office's evil proxy blocks out secure IMAP). I access the webmail client via SSL with a self signed cert. Since I added the cert to Firefox's list of exemptions while I was at home, on my private network, I know there was no MITM attack. Now I can access my home server from work using this cert no problem. If someone were to try a MITM attack, then the cert would change, and Firefox would complain (and I'd start updating my resume in an attempt to escape my evil IT department. :)

Re:Cases where Self Signed Certs are OK.

[cbhacking]

For personal use, or within a secure distribution, self-signed is great. On the greater Internet, however, nobody will know whether they should trust the self-signed cert or not, so most people won't add it.

Please back up the "economic hell to pay"

[ODBOL]

"A CA gets compromised in the way you're discussing, and there's economic hell to pay." I hope that we won't post this assertion too many more times before someone provides at least one example where a CA has paid some "economic hell," or at least a plausible scenario regarding the mechanism by which this "econonomic hell" is paid. I have seen no evidence whatsoever that a failure of a CA will lead to large scale refusal to accept its certificates.

SSH uses the "self signed model"

[Anonymous Coward]

SSH uses a self signed model and yet on the other hand this is typically considered to be "better" than telnet... Why is this given that SSH can be easily subverted by a man in the middle attack just like with self signed certs!

By the arguments of those who claim SSC (self signed certs) are useless then so also is SSH because it fundamentally relies on that first contact where it pops up the warning saying "do you trust this host" is actually talking to the correct remote system. If this was subverted then you are stuffed from that point forwards

I think the point is that people generally consider that it's "hard" to continually perpetuate a MITM attack and likely there will be some clues of certs changing from time to time. I think the same argument could be made for SSC on websites. For logging in to read my email or similar low risk activities I would personally prefer a "probably" encrypted and at most intercepted by a small number of attackers connection than a completely open and visible to all connection.

Sure it's not good enough for big biz sending CC numbers over, but to be honest even there certs are a half arsed solution waiting for the CC companies to finally discover public key encryption... A small USB payment dongle (or cell phone program or whatever) would allow secure payments over an unsecured network...

Verisign incorrectly issued certificate

[cohomology]

An example of an incorrectly granted code-signing certificate.

http://www.schneier.com/crypto-gram-0104.html#7
http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx