18 ms·

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. The

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and bigger. 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". But so what if he's cool? Yeah I like my banking website to be "cool" but for 200 bucks I can be just as "cool". A few years back the browsers started putting extra bling on the URL bar if the coolness factor was high enough - if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge. And they should, that means someone had to fax over vials of blood with the governor's seal that it's a legitimate institute in that state or province. But my little 200 dollar, not pulsating but still green certificate means "yeah digitalsushi definitely had 200 bucks and a fax machine, or at least was hostmaster@digitalsushi.com for damned sure". And that is good enough for users. No errors? It's legit. What's the difference between me coughing up 200 bucks to make that URL bar green, and then bright red with klaxons cause I didn't cough up the 200 bucks to be sure I am the owner of a personal domain? Like I said, a racket. The certificate authorities love causing a panic. But don't tell me users are any safer just 'cause I had 200 bucks. They're not. The cert is just for warm and fuzzies. The encryption is to keep snoops out. If I made a browser, I would have 200 dollar "hostmaster" verification be some orange, cautious URL bar - "this person has a site that we have verified to the laziest extent possible without getting sued for not even doing anything at all". But then I probably wouldn't be getting any tips in my jar from the CAs at the end of the day.

tatterdemalion 12y ago
The warning pages are really ridiculous. Why doesn't every HTTP page show a warning you have to click through? But it's not like MITM attacks are not real. CAs don't realistically do a thing about them, but it is true that you can't trust that your connection is private based on TLS alone. (unless you're doing certificate pinning or you have some other solution).
- bdhe 12y ago
  Because HTTP does not imply security, HTTPS does. Without proper certificates, these guarantees are diluted; hence the warnings.
- pde3 12y ago
  You're absolutely right. From first principles, HTTP should have a louder warning than self-signed HTTPS. Our hope is that Let's Encrypt will reduce the barriers to CA-signed HTTPS sufficiently, that it will become realistic for browsers to show warning indicators on HTTP. If they did that today, millions of sites would complain, "why are you forcing us to pay money to CAs, and deal with the incredible headache of cert installation and management?". With Let's Encrypt, the browsers can point to a simple, single-command solution.
  - tatterdemalion 12y ago
    Thanks for doing this. It's really great and its something that clearly needs to happen. The next step will be to replace the CA system with something actually secure, but that comes after we move the web to a place where most websites are at least trying.
    - pde3 12y ago
      We'll be in a position to deploy defenses like pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt) for site operators who want more protection against the structural problems of the CA system. That will need to be implemented with care, but it should be possible.
- srj 12y ago
  Eventually maybe the browsers will do that. Currently far too many websites are HTTP-only to allow for that behavior, but if that changes and the vast majority of the web is over SSL it would make sense to start warning for HTTP connections. That would further reduce the practicality of SSL stripping attacks.
- 12y ago
Someone1234 12y ago
I totally agree that CAs are a racket. There's zero competition in that market and the gate-keepers (Microsoft, Mozilla, Apple, and Google) keep it that way (mostly Microsoft however). That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no assurances that the two end points are who they claim to be. So verification is a legitimate requirement and it does have a legitimate cost. The problem is the LOWEST barriers to entry are set too high, this has become a particular problem when insecure WiFi is so common and even "basic" web-sites really need HTTPS (e.g. this one).
- 3pt14159 12y ago
  It is not a legitimate requirement. HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy. In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in. Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
  - geofft 12y ago
    That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...
  - Someone1234 12y ago
chc 12y ago
The thing is, without a chain of trust, the self-signed certificate might be from you or it might be from the "snoops" themselves. Certificates that don't contain any identifying information are vulnerable to man-in-the-middle attacks.
bdhe 12y ago
This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. But a man-in-the-middle attack will remove any secrecy encryption provides and to prevent that, we require certificate authorities to perform some minimal checks that public keys delivered to your browser are indeed the correct ones. You've got a point about how warnings are pushing incentives towards more verification, but they serve a purpose that aligns with secrecy of communication.
iancarroll 12y ago
I'm not entirely sure I understand your point, so if I misunderstood you please correct me. First, TLS has three principles that, if you lose one, it becomes essentially uselsss: 1) Authentication - you're talking to the right server 2) Encryption - nobody saw what was sent 3) Verification - nothing was modified in transit Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname. Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)
- SilasX 12y ago
  Encryption without verification is not useless; it protects against snooping.
  - iancarroll 12y ago
    If you don't verify what is sent, I could easily send you a malicious web form. If you don't verify the key or cert behind the connection, anyone can claim to be x site.
    - Tepix 12y ago
      Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance. Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).
      - iancarroll 12y ago
        That would make dragnet surveillance easier. Just MITM everything and you'll be the Trusted Source™ for all traffic.
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.
davidgerard 12y ago
I'm pissed off 'cos I'm on the board for rationalwiki.org and we have to pay a friggin' fortune to get the shiny green address bar ... because end users actually care, even as we know precisely what snake oil the whole SSL racket is. Gah.
michaelbuckbee 12y ago
Here's some comparison screenshots of the "bling" that is being described (hard to even tell that some of these sites are SSL'd without getting the EV) https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design https://www.expeditedssl.com/pages/visual-security-browser-s...
exelius 12y ago
It's not enough to keep the snoops out - you need to KNOW you're keeping the snoops out. That's what SSL helps with. A certificate is just a key issued by a public (aka trusted) authority. Sites can also choose to verify the certificate: if this is done, even if a 3rd party can procure a fake cert, if they don't have the same cert the web server uses, they can't snoop the traffic. Site: Here's my public key. Use it to verify that anything I sent you came from me. But don't take my word for it, verify it against a set of trusted authorities pre-installed on your machine. Browser: Ok, your cert checks out. Here's my public key. You can use it for the same. Site: Ok, now I need you to reply this message with the entire certificate chain you have for me to make sure a 3rd party didn't install a root cert and inject keys between us. Encrypt it with both your private key and my public key. Browser: Ok, here it is: ASDSDFDFSDFDSFSD. Site: That checks out. Ok, now you can talk to me. This is what certificates help with. There are verification standards that apply, and all the certificate authorities have to agree to follow these standards when issuing certain types of SSL certificates. The most stringent, the "Green bar" with the entity name, often require verification through multiple means, including bank accounts. Certificate authorities that fail to verify properly can have their issuing privileges revoked (though this is hard to do in practice, it can be done).
kaoD 12y ago
Perhaps you should understand a system before slandering it? As others have said, encryption without authentication is useless. Running a CA has an associated cost, including maintenance, security, etc. That's what you pay for when you acquire a certificate. Whether current market prices' markup is too high would be a different question, but paying for a certificate is definitely not spending 200$ to look cool. CAs are the best known way (at the moment) to authenticate through insecure channels (before anyone brings pìnned certs or WoT, read this comment of mine: https://news.ycombinator.com/item?id=8616766 https://news.ycombinator.com/item?id=8616766) EDIT: You can downvote all you want but I'm still right. Excuse my tone, but slandering a system without an intimate understanding of the "how"s and the "why"s (i.e. spreading FUD) hurts everyone in the long run.
- jsmthrowaway 12y ago
  That's the third comment of yours in which I've seen you taunt downvoters via edits in this thread alone. That's why I'm downvoting you. Knock it off, please.
  - kaoD 12y ago
    I'm sorry it came across as a taunt, I didn't mean it like that. Downvote sprees without an explanation detract from healthy discussion since they basically mean "I'm so mad about how wrong you are that I don't even care about why you think you are right". I guess I'll just ignore them...
    - dang 12y ago
      Do please ignore them. That's what the HN guidelines ask.
syshax 12y ago
I have some certificates through RapidSSL, and when they send me reminders to renew, the e-mails come with this warning: "Your certificate is due to expire. If your certificate expires, your site will no longer be encrypted." Just blatantly false.
- organsnyder 12y ago
  They might as well say something even more ominous: "If your certificate expires, your site will no longer be accessible." Of course, we know that's not true either, but try explaining to your visitors how to bypass the security warning (newer browsers sure don't make it obvious, even if you know to look for it).
tptacek 12y ago
Without some kind of authentication, the encryption TLS offers provides no meaningful security. It might as well be an elaborate compression scheme. The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session. But of course, real attackers trivially see all the the traffic for a session, because they snare attackers with routing, DNS, and layer 2 redirection. What's especially baffling about self-signed certificate advocacy is the implied threat model. Low- and mid-level network attackers and crime syndicates can't compromise a CA. Every nation state can, of course (so long as the site in question isn't public-key-pinned). But nation states are also uniquely capable of MITMing connections!
- SilasX 12y ago
  >The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption). The threat model would be eavesdroppers who can't control the channel, only look. Using the SS cert would be better than an unencrypted connection, though still shouldn't be represented as being as secure as full TLS. As it stands, the server is either forced to wait to get the cert, or serve unencrypted such that all attackers can see.
  - tptacek 12y ago
    There are no such attackers.
    - xnull2guest 12y ago
      Do you think that with public key pinning self-signed certs begin to make sense? Also, do you feel that CAs and the PKI system do provide appropriate authentication (this being a cost-benefit rather than a 100%-correctness analysis)?
Buge 12y ago
I just bought a cert on Saturday for $9. It's less than the domain name.
- seanc722 12y ago
  Can get them free for web use. Not sure where he is coming from.
  - ericd 12y ago
    Wildcard SSL certs are ~$100/year. Those have always been much more of a racket, but they're so worth the extra cost to set them up once on your load balancers and not have to think about SSL certs again for 5+ years.
- lmm 12y ago
  $9 is a big step up from free, which is what the rest of my blog costs.
  - Buge 12y ago
    Is your blog a .tk site? Where else would you get a free domain?
wooster20 12y ago
I'm all for CAs to burn in a special hell. The other cost, though, was always getting a unique IP. Is that still a thing? Has someone figured out multiple certificates for different domains on the same IP? Weren't we running out of IPv4 at some point?
- schoen 12y ago
  Yes, there are two main mechanisms, each with its own limitations. https://en.wikipedia.org/wiki/SubjectAltName https://en.wikipedia.org/wiki/SubjectAltName https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
spacecowboy_lon 12y ago
no it means a trusted third party has not verifed who you are connecting to is who he/she says they are
lectrick 12y ago
Wasn't WOT (Web Of Trust) supposed to fix this? Basically, I get other people to sign my public key asserting that it's actually me and not someone else, and if enough people do that it's considered "trusted", but in a decentralized fashion that's not tied to "authorities"?
hobarrera 12y ago
> 200 bucks for us to say he's cool There are trusted free certificates as well, like the ones from StartSSL. > if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge Yeah, $10 000 and legal documentation proving that they are exactly the same legal entity as the one stated on the certificated. All verified by a provider that's been deemed trustworthy by your browser's developers. Finally, if a certificate is self-signed, it generally should be a large warning to most users: the certificate was made by an unknown entity, and anybody may be intercepting the comunication. Power-users understand when self-signed CAs are used, but they don't get scared of red warnings either, so that's not an issue.

tatterdemalion 12y ago

The warning pages are really ridiculous. Why doesn't every HTTP page show a warning you have to click through? But it's not like MITM attacks are not real. CAs don't realistically do a thing about them, but it is true that you can't trust that your connection is private based on TLS alone. (unless you're doing certificate pinning or you have some other solution).

bdhe 12y ago
Because HTTP does not imply security, HTTPS does. Without proper certificates, these guarantees are diluted; hence the warnings.
pde3 12y ago
You're absolutely right. From first principles, HTTP should have a louder warning than self-signed HTTPS. Our hope is that Let's Encrypt will reduce the barriers to CA-signed HTTPS sufficiently, that it will become realistic for browsers to show warning indicators on HTTP. If they did that today, millions of sites would complain, "why are you forcing us to pay money to CAs, and deal with the incredible headache of cert installation and management?". With Let's Encrypt, the browsers can point to a simple, single-command solution.
- tatterdemalion 12y ago
  Thanks for doing this. It's really great and its something that clearly needs to happen. The next step will be to replace the CA system with something actually secure, but that comes after we move the web to a place where most websites are at least trying.
  - pde3 12y ago
    We'll be in a position to deploy defenses like pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt) for site operators who want more protection against the structural problems of the CA system. That will need to be implemented with care, but it should be possible.
srj 12y ago
Eventually maybe the browsers will do that. Currently far too many websites are HTTP-only to allow for that behavior, but if that changes and the vast majority of the web is over SSL it would make sense to start warning for HTTP connections. That would further reduce the practicality of SSL stripping attacks.
12y ago

Someone1234 12y ago

I totally agree that CAs are a racket. There's zero competition in that market and the gate-keepers (Microsoft, Mozilla, Apple, and Google) keep it that way (mostly Microsoft however). That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no assurances that the two end points are who they claim to be. So verification is a legitimate requirement and it does have a legitimate cost. The problem is the LOWEST barriers to entry are set too high, this has become a particular problem when insecure WiFi is so common and even "basic" web-sites really need HTTPS (e.g. this one).

3pt14159 12y ago
It is not a legitimate requirement. HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy. In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in. Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
- geofft 12y ago
  That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...
- Someone1234 12y ago

chc 12y ago

The thing is, without a chain of trust, the self-signed certificate might be from you or it might be from the "snoops" themselves. Certificates that don't contain any identifying information are vulnerable to man-in-the-middle attacks.

bdhe 12y ago

iancarroll 12y ago

I'm not entirely sure I understand your point, so if I misunderstood you please correct me. First, TLS has three principles that, if you lose one, it becomes essentially uselsss: 1) Authentication - you're talking to the right server 2) Encryption - nobody saw what was sent 3) Verification - nothing was modified in transit Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname. Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)

SilasX 12y ago
Encryption without verification is not useless; it protects against snooping.
- iancarroll 12y ago
  If you don't verify what is sent, I could easily send you a malicious web form. If you don't verify the key or cert behind the connection, anyone can claim to be x site.
  - Tepix 12y ago
    Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance. Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).
    - iancarroll 12y ago
      That would make dragnet surveillance easier. Just MITM everything and you'll be the Trusted Source™ for all traffic.

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.

davidgerard 12y ago

I'm pissed off 'cos I'm on the board for rationalwiki.org and we have to pay a friggin' fortune to get the shiny green address bar ... because end users actually care, even as we know precisely what snake oil the whole SSL racket is. Gah.

michaelbuckbee 12y ago

Here's some comparison screenshots of the "bling" that is being described (hard to even tell that some of these sites are SSL'd without getting the EV) https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design https://www.expeditedssl.com/pages/visual-security-browser-s...

exelius 12y ago

It's not enough to keep the snoops out - you need to KNOW you're keeping the snoops out. That's what SSL helps with. A certificate is just a key issued by a public (aka trusted) authority. Sites can also choose to verify the certificate: if this is done, even if a 3rd party can procure a fake cert, if they don't have the same cert the web server uses, they can't snoop the traffic. Site: Here's my public key. Use it to verify that anything I sent you came from me. But don't take my word for it, verify it against a set of trusted authorities pre-installed on your machine. Browser: Ok, your cert checks out. Here's my public key. You can use it for the same. Site: Ok, now I need you to reply this message with the entire certificate chain you have for me to make sure a 3rd party didn't install a root cert and inject keys between us. Encrypt it with both your private key and my public key. Browser: Ok, here it is: ASDSDFDFSDFDSFSD. Site: That checks out. Ok, now you can talk to me. This is what certificates help with. There are verification standards that apply, and all the certificate authorities have to agree to follow these standards when issuing certain types of SSL certificates. The most stringent, the "Green bar" with the entity name, often require verification through multiple means, including bank accounts. Certificate authorities that fail to verify properly can have their issuing privileges revoked (though this is hard to do in practice, it can be done).

kaoD 12y ago

Perhaps you should understand a system before slandering it? As others have said, encryption without authentication is useless. Running a CA has an associated cost, including maintenance, security, etc. That's what you pay for when you acquire a certificate. Whether current market prices' markup is too high would be a different question, but paying for a certificate is definitely not spending 200$ to look cool. CAs are the best known way (at the moment) to authenticate through insecure channels (before anyone brings pìnned certs or WoT, read this comment of mine: https://news.ycombinator.com/item?id=8616766 https://news.ycombinator.com/item?id=8616766) EDIT: You can downvote all you want but I'm still right. Excuse my tone, but slandering a system without an intimate understanding of the "how"s and the "why"s (i.e. spreading FUD) hurts everyone in the long run.

jsmthrowaway 12y ago
That's the third comment of yours in which I've seen you taunt downvoters via edits in this thread alone. That's why I'm downvoting you. Knock it off, please.
- kaoD 12y ago
  I'm sorry it came across as a taunt, I didn't mean it like that. Downvote sprees without an explanation detract from healthy discussion since they basically mean "I'm so mad about how wrong you are that I don't even care about why you think you are right". I guess I'll just ignore them...
  - dang 12y ago
    Do please ignore them. That's what the HN guidelines ask.

syshax 12y ago

I have some certificates through RapidSSL, and when they send me reminders to renew, the e-mails come with this warning: "Your certificate is due to expire. If your certificate expires, your site will no longer be encrypted." Just blatantly false.

organsnyder 12y ago
They might as well say something even more ominous: "If your certificate expires, your site will no longer be accessible." Of course, we know that's not true either, but try explaining to your visitors how to bypass the security warning (newer browsers sure don't make it obvious, even if you know to look for it).

tptacek 12y ago

Without some kind of authentication, the encryption TLS offers provides no meaningful security. It might as well be an elaborate compression scheme. The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session. But of course, real attackers trivially see all the the traffic for a session, because they snare attackers with routing, DNS, and layer 2 redirection. What's especially baffling about self-signed certificate advocacy is the implied threat model. Low- and mid-level network attackers and crime syndicates can't compromise a CA. Every nation state can, of course (so long as the site in question isn't public-key-pinned). But nation states are also uniquely capable of MITMing connections!

SilasX 12y ago
>The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption). The threat model would be eavesdroppers who can't control the channel, only look. Using the SS cert would be better than an unencrypted connection, though still shouldn't be represented as being as secure as full TLS. As it stands, the server is either forced to wait to get the cert, or serve unencrypted such that all attackers can see.
- tptacek 12y ago
  There are no such attackers.
  - xnull2guest 12y ago
    Do you think that with public key pinning self-signed certs begin to make sense? Also, do you feel that CAs and the PKI system do provide appropriate authentication (this being a cost-benefit rather than a 100%-correctness analysis)?

Buge 12y ago

I just bought a cert on Saturday for $9. It's less than the domain name.

seanc722 12y ago
Can get them free for web use. Not sure where he is coming from.
- ericd 12y ago
  Wildcard SSL certs are ~$100/year. Those have always been much more of a racket, but they're so worth the extra cost to set them up once on your load balancers and not have to think about SSL certs again for 5+ years.
lmm 12y ago
$9 is a big step up from free, which is what the rest of my blog costs.
- Buge 12y ago
  Is your blog a .tk site? Where else would you get a free domain?

wooster20 12y ago

I'm all for CAs to burn in a special hell. The other cost, though, was always getting a unique IP. Is that still a thing? Has someone figured out multiple certificates for different domains on the same IP? Weren't we running out of IPv4 at some point?

schoen 12y ago
Yes, there are two main mechanisms, each with its own limitations. https://en.wikipedia.org/wiki/SubjectAltName https://en.wikipedia.org/wiki/SubjectAltName https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication

spacecowboy_lon 12y ago

no it means a trusted third party has not verifed who you are connecting to is who he/she says they are

lectrick 12y ago

Wasn't WOT (Web Of Trust) supposed to fix this? Basically, I get other people to sign my public key asserting that it's actually me and not someone else, and if enough people do that it's considered "trusted", but in a decentralized fashion that's not tied to "authorities"?

hobarrera 12y ago

> 200 bucks for us to say he's cool There are trusted free certificates as well, like the ones from StartSSL. > if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge Yeah, $10 000 and legal documentation proving that they are exactly the same legal entity as the one stated on the certificated. All verified by a provider that's been deemed trustworthy by your browser's developers. Finally, if a certificate is self-signed, it generally should be a large warning to most users: the certificate was made by an unknown entity, and anybody may be intercepting the comunication. Power-users understand when self-signed CAs are used, but they don't get scared of red warnings either, so that's not an issue.