18 ms·

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven t

by pilif 12y ago

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private. Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server. So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown. But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue. This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have. The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

lazyjones 12y ago
> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default. FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...
- iancarroll 12y ago
  The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.
  - lazyjones 12y ago
    They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate. PS. nice (presumably political) downvote further up ...
    - iancarroll 12y ago
      One would hope certificate transparency would help fix this problem. (for the record, I didn't downvote you)
    - deleted 12y ago
      [deleted]
    - MichaelGG 12y ago
      The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business. So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA. For lesser sites and narrow targets, this may not be true.
      - deleted 12y ago
        [deleted]
      - joshuak 12y ago
        This is precisely the problem with centralized security authorities. As we've seen a state actor can easily force a central authority to share it's private key, thereby granting the state actor the ability to untraceably create it's own certificate chains. It would also have to control the wire for the attack target, but via wire tapping laws that is already a solved problem. Because they control the connection of the attack target, I don't see how the fact that the certificate chain was compromised would ever become public knowledge. Web of trust was designed to address the central authority weakness, but itself apparently has scalability issues, although I'm unclear on why.
- im3w1l 12y ago
  I agree. A more common MITM, and that it actually would prevent, comes from a rogue wifi operator.
- duaneb 12y ago
  > FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ... And it's only going to get worse as SHA-1 become more and more affordable to crack.
  - pde3 12y ago
    The CAs have agreed to stop using SHA-1 by 2016, and Let's Encrypt will launch with something stronger on day one. But SHA-1 attacks are going to be a huge problem all over our protocol stack :(
Joeri 12y ago
Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.
- zymhan 12y ago
  The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
  - M2Ys4U 12y ago
    CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.
    - mbrubeck 12y ago
      This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.
    - jbinto 12y ago
      Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session. If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.
      - M2Ys4U 12y ago
Spooky23 12y ago
The use case for the CA system is to prevent conventional criminal activity -- not state-level spying or lawful intercept. The $200 is just a paper trail that links the website to either a purchase transaction or some sort of communication detail. The self-signed cert risk has nothing to do with the NSA... if it's your cert or a known cert, you add it to the trust store, otherwise, you don't.
danielweber 12y ago
Browsers shouldn't silently accept self-signed, but there is a class of servers where self-signed is the best we've got: connecting to embedded devices. If I want to talk to the new printer or fridge I got over the web, they have no way of establishing trust besides Tacking my first request to them.
- na85 12y ago
  Oh god, they have internet fridges now? What on earth for?
  - icebraining 12y ago
    http://en.wikipedia.org/wiki/Internet_refrigerator http://en.wikipedia.org/wiki/Internet_refrigerator
- icebraining 12y ago
  Technically, there's no reason why a fridge couldn't have a signed cert tied to some dynamic DNS (e.g. <fridge-serial-number>.<manufacturer>.<tld>).
  - jerf 12y ago
    But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.
    - icebraining 12y ago
      Allow the cert to be configurable, then the company can use its internal CA to give certs to all its appliances.
      - jerf 12y ago
        Yes, that's the status quo, and has been for a while. The point is that's currently the best you can do. For boxes without external exposure, this work won't change anything, but a standardized protocol for dealing with boxes with external exposure would still help some use cases.
krick 12y ago
> It's just the best that we currently have. No, I wouldn't say so. Having SSL is better than having nothing pretty much on any site. But if you don't want to pay $200 somebody for nothing, you would probably consider using http by default on your site, because it just looks "safer" to the user that knows nothing about cryptography because of how browsers behave. Which is nonsense. It's worse than nothing. And CA are not "authorities" at all. They could lie to you, they could be compromised. Of course, the fact that this certificate has been confirmed by "somebody" makes it a little more reliable than if it never was confirmed by anyone at all, but these "somebodies", CA, don't have any control over the situation, it's just some guys that came up with idea to make money like that early enough. You are as good CA as Symantec is, you can just start selling certificates and it would be the same — except, well, you are just some guy, so browsers wouldn't accept these certificates so it's worth nothing. It's all just about trust, and I'm not sure I trust Symantec more than I trust you. (And I don't mean I actually trust you, by the way.) For everyone else it's not really about SSL, security and CAs, it's just about how popular browsers behave. So, no, monopolies existing for the reason they are allowed to do something are never good. Only if they do it for free.
- rogerbinns 12y ago
  > And CA are not "authorities" at all. They could lie to you, they could be compromised. Actually just read their terms of service, which may as well be summarised as "we issue certificates for entertainment purposes only".
itistoday2 12y ago
> The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with. We do have a solution that does accept self-signed certificates. The remaining pieces need to be finished and the players need to come together though: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight: http://www.meetup.com/San-Francisco-Bitcoin-Social/events/180197882/ http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18... Let's Encrypt seems like the right "next step", but we still need to address the man-in-the-middle problem with HTTPS, and that is something the blockchain will solve.
SilasX 12y ago
>So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown. Maybe a security-conscious person thinks that, but the typical user does not knowingly choose http over https, and thus the danger of MitM and (unaccepted) snooping is at least as large for the former. So it's somewhat debatable why we'd warn users that "hey, someone might be reading this and impersonating the site" for self-signed https but not http.
chetanahuja 12y ago
"Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private." This is misguided thinking, pure and simple. Because of this line of thinking, your everyday webmaster has been convinced that encrypting data on a regular basis is more trouble than it's worth and allowed NSA (or the Chinese or the Iranian or what have you) authorities to simply put in a tap to slurp the entire internet without even going through the trouble of targeting and impersonating. Basically, this is the thinking that has enabled dragnet surveillance of the internet with such ease.
- riffraff 12y ago
  but as user I can understand that an http site is insecure, while a self signed certificate might lead me into a false sense of security.
  - chetanahuja 12y ago
    That's the proffered reasoning as we all know. But the actual outcome (to quote rufb from this comment https://news.ycombinator.com/item?id=8625739 https://news.ycombinator.com/item?id=8625739) Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME Tell me how the logic works here (for an average user).
    - lsh123 12y ago
      I can self-sign a certificate for gmail, the browser correctly warns about potential BIG security issues with it.
    - RRRA 12y ago
      Not considering the many holes, cyphersuites, running TLS 1.3+ etc. ( http://wingolog.org/archives/2014/10/17/ffs-ssl http://wingolog.org/archives/2014/10/17/ffs-ssl ) ...it should probably look like this: Safe against active attacks: Encrypted (Certified) COOL GREEN Safe against passive attacks: Encrypted (Self-Signed) SCARY ORANGE Safe against world peace, ie. UNSAFE: Unencrypted EVIL RED
rufb 12y ago
So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.
- jud_white 12y ago
  To know something is insecure can be acceptable. To think something is secure when it isn't can be far more dangerous. I'm considering secure to mean encrypted and identity reasonably verified. Whatever your thoughts on the CA process it serves a purpose. There are plenty of other things to complain about. EV for one.
- IgorPartola 12y ago
  > Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me. > Unencrypted NOTHING / NEUTRAL CHROME This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don't even have to think about this case. Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA's. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain. This is all castles in the sky, but IMO that's the correct solution.
  - Xeoncross 12y ago
    I'm not sure you should completely cut off anyone else but your registrar from holding the power to grant you certs. As long as you can transfer the domain out I guess it's not too bad.
kybernetikos 12y ago
There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc). There are certainly other options too: here's my suggestion- The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it. Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people. It's basically what we do for ssh connections to new hosts.
- userbinator 12y ago
  The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to. I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed on them.
  - jcase 12y ago
    With SSH you usually own both endpoints (or at least trusting your cloud provider). The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries. I'm putting my eggs on certificate pinning.
- xorcist 12y ago
  How would you rotate keys with that scheme?
  - 12y ago
wbillingsley 12y ago
Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network". It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to nail all the office doors open and require you to sign a form in triplicate that you are aware the door is not completely soundproof before you are allowed to close it to make a phone call. (Or jump through a long registration process to have someone come and install a heavy steel soundproofed door which will require replacement every 12 months.) After all, if you're closing the door, it's clearly meant to be private. And if we can't guarantee complete security against sound leaks to people holding their ear to a glass on the other side, surely you mustn't be allowed to have a door.
- lazaroclapp 12y ago
  The person next to you in cafe can MITM a self-signed TLS connection just as easily as the NSA; and the NSA can probably MITM a CA-signed TLS session, since the U.S. government owns or has access to quite a few root certificates. So, "no self-signed certs" is really a measure to protect you from the lowest level of threat. Almost any attacker than can MITM http can MITM https with self-signed certs that you never verify in any way. Encryption without authentication is useless in communications.
moe 12y ago
The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Blindly trust everyone who manages to exert control over any one of the 200+ "Certificate Authorities" that someone chose to bake into my browser.
- nnnnni 12y ago
  ...and then if the fingerprint changes, you get something like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  - deleted 12y ago
    [deleted]
  - dscrd 12y ago
    ... and then you do rm .ssh/known_hosts and try again :P
    - lorenzhs 12y ago
      ssh-keygen -f ~/.ssh/known_hosts -R 123.45.67.89
      - corobo 12y ago
        You have probably just saved me.. minutes of time over the course of a year! But seriously thanks, I was going into the known_hosts file and manually deleting the offending line :)
      - erpellan 12y ago
        If you get past the terrifying warning, it even gives you the command to copy and paste. You don't even have to type it!
qewrffewqwfqew 12y ago
> or to NSA which Nah. The NSA, or any adversary remotely approaching them in resources, has the ability to generate certificates that are on your browser's trust chain. Self-signed and unknown-CA warnings suggest that a much lower level attacker may be interfering.
kentonv 12y ago
> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities. But I agree with the sentiment. :)
justinreeves 12y ago
Moxie Marlinspike's Perspectives addon for Firefox was a good attempt to resolve some of the problems with self-signed certs. Unfortunately, no browsers adopted the project, and it is no longer compatible with Firefox. There are a couple forks which are still in development, but they are pretty underdeveloped. I wonder if Mozilla would be more likely to accept this kind of project into Firefox today, compared to ~4 years ago when it was first released, now that privacy and security may be more important topic to the users of the browser.
jules 12y ago
Here's one thing that's NOT the solution: throwing out all encryption entirely. Secure vs insecurse is a gradient. The information that you're now talking to the same entity as you were when you first viewed the site is valuable. For example it means that you can be sure that you're talking to the real site when you log in to it on a public wifi, provided you have visited that site before. In fact, I trust a site that's still the same entity as when I first visited it a whole lot more than a site with a new certificate signed by some random CA. In practice the security added by CAs is negligible, so it makes no sense to disable/enable encryption based on that. Certificates don't even solve the problem they attempt to solve, because in practices there are too many weaknesses in the chain. When you first downloaded firefox/chrome, who knows that the NSA didn't tamper with the CA list? (not that they'd need to)
tootie 12y ago
It's interesting that your boogeyman in the NSA and not scammers. I think scammers are 1000X more likely. Escpecially since the NSA can just see the decrypted traffic from behind the firewall. There's no technology solution for voluntarily leaving the backdoor open.
jasonjei 12y ago
Just a small nitpick: I'm pretty sure the NSA has access to a CA to make it look legit.
lectrick 12y ago
The solution, at least for something decentralized, seems to be a web of trust established by multiple other identities signing your public key with some assumption of assurance that they have a reasonable belief that your actual identity is in fact represented by that public key. That's what PGP/GPG people seem to do, anyway. Why can't I get my personally-generated cert signed by X other people who vouch for its authenticity?

by pilif 12y ago

lazyjones 12y ago

> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default. FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...

iancarroll 12y ago
The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.
- lazyjones 12y ago
  They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate. PS. nice (presumably political) downvote further up ...
  - iancarroll 12y ago
    One would hope certificate transparency would help fix this problem. (for the record, I didn't downvote you)
  - deleted 12y ago
    [deleted]
  - MichaelGG 12y ago
    The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business. So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA. For lesser sites and narrow targets, this may not be true.
    - deleted 12y ago
      [deleted]
    - joshuak 12y ago
      This is precisely the problem with centralized security authorities. As we've seen a state actor can easily force a central authority to share it's private key, thereby granting the state actor the ability to untraceably create it's own certificate chains. It would also have to control the wire for the attack target, but via wire tapping laws that is already a solved problem. Because they control the connection of the attack target, I don't see how the fact that the certificate chain was compromised would ever become public knowledge. Web of trust was designed to address the central authority weakness, but itself apparently has scalability issues, although I'm unclear on why.
im3w1l 12y ago
I agree. A more common MITM, and that it actually would prevent, comes from a rogue wifi operator.
duaneb 12y ago
> FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ... And it's only going to get worse as SHA-1 become more and more affordable to crack.
- pde3 12y ago
  The CAs have agreed to stop using SHA-1 by 2016, and Let's Encrypt will launch with something stronger on day one. But SHA-1 attacks are going to be a huge problem all over our protocol stack :(

Joeri 12y ago

Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.

zymhan 12y ago
The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
- M2Ys4U 12y ago
  CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.
  - mbrubeck 12y ago
    This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.
  - jbinto 12y ago
    Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session. If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.
    - M2Ys4U 12y ago

Spooky23 12y ago

The use case for the CA system is to prevent conventional criminal activity -- not state-level spying or lawful intercept. The $200 is just a paper trail that links the website to either a purchase transaction or some sort of communication detail. The self-signed cert risk has nothing to do with the NSA... if it's your cert or a known cert, you add it to the trust store, otherwise, you don't.

danielweber 12y ago

Browsers shouldn't silently accept self-signed, but there is a class of servers where self-signed is the best we've got: connecting to embedded devices. If I want to talk to the new printer or fridge I got over the web, they have no way of establishing trust besides Tacking my first request to them.

na85 12y ago
Oh god, they have internet fridges now? What on earth for?
- icebraining 12y ago
  http://en.wikipedia.org/wiki/Internet_refrigerator http://en.wikipedia.org/wiki/Internet_refrigerator
icebraining 12y ago
Technically, there's no reason why a fridge couldn't have a signed cert tied to some dynamic DNS (e.g. <fridge-serial-number>.<manufacturer>.<tld>).
- jerf 12y ago
  But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.
  - icebraining 12y ago
    Allow the cert to be configurable, then the company can use its internal CA to give certs to all its appliances.
    - jerf 12y ago
      Yes, that's the status quo, and has been for a while. The point is that's currently the best you can do. For boxes without external exposure, this work won't change anything, but a standardized protocol for dealing with boxes with external exposure would still help some use cases.

krick 12y ago

> It's just the best that we currently have. No, I wouldn't say so. Having SSL is better than having nothing pretty much on any site. But if you don't want to pay $200 somebody for nothing, you would probably consider using http by default on your site, because it just looks "safer" to the user that knows nothing about cryptography because of how browsers behave. Which is nonsense. It's worse than nothing. And CA are not "authorities" at all. They could lie to you, they could be compromised. Of course, the fact that this certificate has been confirmed by "somebody" makes it a little more reliable than if it never was confirmed by anyone at all, but these "somebodies", CA, don't have any control over the situation, it's just some guys that came up with idea to make money like that early enough. You are as good CA as Symantec is, you can just start selling certificates and it would be the same — except, well, you are just some guy, so browsers wouldn't accept these certificates so it's worth nothing. It's all just about trust, and I'm not sure I trust Symantec more than I trust you. (And I don't mean I actually trust you, by the way.) For everyone else it's not really about SSL, security and CAs, it's just about how popular browsers behave. So, no, monopolies existing for the reason they are allowed to do something are never good. Only if they do it for free.

rogerbinns 12y ago
> And CA are not "authorities" at all. They could lie to you, they could be compromised. Actually just read their terms of service, which may as well be summarised as "we issue certificates for entertainment purposes only".

itistoday2 12y ago

> The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with. We do have a solution that does accept self-signed certificates. The remaining pieces need to be finished and the players need to come together though: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight: http://www.meetup.com/San-Francisco-Bitcoin-Social/events/180197882/ http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18... Let's Encrypt seems like the right "next step", but we still need to address the man-in-the-middle problem with HTTPS, and that is something the blockchain will solve.

SilasX 12y ago

>So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown. Maybe a security-conscious person thinks that, but the typical user does not knowingly choose http over https, and thus the danger of MitM and (unaccepted) snooping is at least as large for the former. So it's somewhat debatable why we'd warn users that "hey, someone might be reading this and impersonating the site" for self-signed https but not http.

chetanahuja 12y ago

"Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private." This is misguided thinking, pure and simple. Because of this line of thinking, your everyday webmaster has been convinced that encrypting data on a regular basis is more trouble than it's worth and allowed NSA (or the Chinese or the Iranian or what have you) authorities to simply put in a tap to slurp the entire internet without even going through the trouble of targeting and impersonating. Basically, this is the thinking that has enabled dragnet surveillance of the internet with such ease.

riffraff 12y ago
but as user I can understand that an http site is insecure, while a self signed certificate might lead me into a false sense of security.
- chetanahuja 12y ago
  That's the proffered reasoning as we all know. But the actual outcome (to quote rufb from this comment https://news.ycombinator.com/item?id=8625739 https://news.ycombinator.com/item?id=8625739) Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME Tell me how the logic works here (for an average user).
  - lsh123 12y ago
    I can self-sign a certificate for gmail, the browser correctly warns about potential BIG security issues with it.
  - RRRA 12y ago
    Not considering the many holes, cyphersuites, running TLS 1.3+ etc. ( http://wingolog.org/archives/2014/10/17/ffs-ssl http://wingolog.org/archives/2014/10/17/ffs-ssl ) ...it should probably look like this: Safe against active attacks: Encrypted (Certified) COOL GREEN Safe against passive attacks: Encrypted (Self-Signed) SCARY ORANGE Safe against world peace, ie. UNSAFE: Unencrypted EVIL RED

rufb 12y ago

So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.

jud_white 12y ago
To know something is insecure can be acceptable. To think something is secure when it isn't can be far more dangerous. I'm considering secure to mean encrypted and identity reasonably verified. Whatever your thoughts on the CA process it serves a purpose. There are plenty of other things to complain about. EV for one.
IgorPartola 12y ago
> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me. > Unencrypted NOTHING / NEUTRAL CHROME This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don't even have to think about this case. Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA's. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain. This is all castles in the sky, but IMO that's the correct solution.
- Xeoncross 12y ago
  I'm not sure you should completely cut off anyone else but your registrar from holding the power to grant you certs. As long as you can transfer the domain out I guess it's not too bad.

kybernetikos 12y ago

There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc). There are certainly other options too: here's my suggestion- The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it. Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people. It's basically what we do for ssh connections to new hosts.

userbinator 12y ago
The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to. I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed on them.
- jcase 12y ago
  With SSH you usually own both endpoints (or at least trusting your cloud provider). The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries. I'm putting my eggs on certificate pinning.
xorcist 12y ago
How would you rotate keys with that scheme?
- 12y ago

wbillingsley 12y ago

Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network". It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to nail all the office doors open and require you to sign a form in triplicate that you are aware the door is not completely soundproof before you are allowed to close it to make a phone call. (Or jump through a long registration process to have someone come and install a heavy steel soundproofed door which will require replacement every 12 months.) After all, if you're closing the door, it's clearly meant to be private. And if we can't guarantee complete security against sound leaks to people holding their ear to a glass on the other side, surely you mustn't be allowed to have a door.

lazaroclapp 12y ago
The person next to you in cafe can MITM a self-signed TLS connection just as easily as the NSA; and the NSA can probably MITM a CA-signed TLS session, since the U.S. government owns or has access to quite a few root certificates. So, "no self-signed certs" is really a measure to protect you from the lowest level of threat. Almost any attacker than can MITM http can MITM https with self-signed certs that you never verify in any way. Encryption without authentication is useless in communications.

moe 12y ago

The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Blindly trust everyone who manages to exert control over any one of the 200+ "Certificate Authorities" that someone chose to bake into my browser.

nnnnni 12y ago
...and then if the fingerprint changes, you get something like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- deleted 12y ago
  [deleted]
- dscrd 12y ago
  ... and then you do rm .ssh/known_hosts and try again :P
  - lorenzhs 12y ago
    ssh-keygen -f ~/.ssh/known_hosts -R 123.45.67.89
    - corobo 12y ago
      You have probably just saved me.. minutes of time over the course of a year! But seriously thanks, I was going into the known_hosts file and manually deleting the offending line :)
    - erpellan 12y ago
      If you get past the terrifying warning, it even gives you the command to copy and paste. You don't even have to type it!

qewrffewqwfqew 12y ago

> or to NSA which Nah. The NSA, or any adversary remotely approaching them in resources, has the ability to generate certificates that are on your browser's trust chain. Self-signed and unknown-CA warnings suggest that a much lower level attacker may be interfering.

kentonv 12y ago

> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities. But I agree with the sentiment. :)

justinreeves 12y ago

Moxie Marlinspike's Perspectives addon for Firefox was a good attempt to resolve some of the problems with self-signed certs. Unfortunately, no browsers adopted the project, and it is no longer compatible with Firefox. There are a couple forks which are still in development, but they are pretty underdeveloped. I wonder if Mozilla would be more likely to accept this kind of project into Firefox today, compared to ~4 years ago when it was first released, now that privacy and security may be more important topic to the users of the browser.

jules 12y ago

Here's one thing that's NOT the solution: throwing out all encryption entirely. Secure vs insecurse is a gradient. The information that you're now talking to the same entity as you were when you first viewed the site is valuable. For example it means that you can be sure that you're talking to the real site when you log in to it on a public wifi, provided you have visited that site before. In fact, I trust a site that's still the same entity as when I first visited it a whole lot more than a site with a new certificate signed by some random CA. In practice the security added by CAs is negligible, so it makes no sense to disable/enable encryption based on that. Certificates don't even solve the problem they attempt to solve, because in practices there are too many weaknesses in the chain. When you first downloaded firefox/chrome, who knows that the NSA didn't tamper with the CA list? (not that they'd need to)

tootie 12y ago

It's interesting that your boogeyman in the NSA and not scammers. I think scammers are 1000X more likely. Escpecially since the NSA can just see the decrypted traffic from behind the firewall. There's no technology solution for voluntarily leaving the backdoor open.

jasonjei 12y ago

Just a small nitpick: I'm pretty sure the NSA has access to a CA to make it look legit.

lectrick 12y ago

The solution, at least for something decentralized, seems to be a web of trust established by multiple other identities signing your public key with some assumption of assurance that they have a reasonable belief that your actual identity is in fact represented by that public key. That's what PGP/GPG people seem to do, anyway. Why can't I get my personally-generated cert signed by X other people who vouch for its authenticity?