Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Trust me, that is not an accusation I bandy about lightly.

     <rant intensity="120%">
It's a scam in that SSL purports to verify identity, when really you're trusting the CA to handle that; some do more, some do less, there's no standard, no real accountability beyond major cockups when the community decides to disown you out of necessity for bad behavior (see Diginotar from not that long ago). Having a CA signed cert proves nothing beyond that you gave some person who is trusted some amount of money who ostensibly verified something.

It's a racket in its implementation. The PKI model used nowadays is rotten and exploitative. Renewals which exist as a pure profit vehicle for CAs (upwards of $100 to run some code and generate a hash? Fkn seriously?), the implementation in every browser which treats a self-signed certificate as coming from a known bad guy, or the slightest misconfiguration as same.

But every single user out there has it drilled into their head to look for the little lock (or nowadays, the much more expensive by a factor of ten or so green bar) before shopping, and every browser out there throws really scary looking errors (Chrome's red screen of doom) for something so much as an expiration date. The CA's can effectively say "Gee, that's a nice commerce website you have there, would be a shame if something were to happen to it and all your customers got scared off since you didn't pay your protec^H^H^H^H renewal fee" - Some basically do, especially around renewal time.

Charging to regenerate or revoke a certificate (again, completely automated processes with zero human interaction required) is just rent-seeking dick behavior of the highest order.

Why do I have to pay upwards of $100 for a wildcard certificate? They don't cost the CA anymore to issue or handle, it's identical to any other certificate except the CN field is written slightly differently. No, the fuckers expect me to either pay for a massively overpriced bit of hashed code or pay lots of times for slightly different overpriced bits of hashed code. Either way, i'm getting screwed. All so people who visit my website don't get scary and misleading warnings.



  the implementation in every browser which treats a self-signed certificate as coming from a known bad guy
Ah, you are a "self signed certificates should be accepted" guy. I very much don't agree there.

A self-signed certificate effectively gives none of the protection of a cert signed by a trusted CA so the warnigs areperfectly valid. Of course self-signed certificates are perfectly valid in specific communities: a company might sign the certificates for all its internal apps themselves and make sure their standard employee desktops & laptops trust their internal CA, or you could sign your own and have your friends and other contacts install your CA as a trusted one. But for public use they are simply not valid.

The commonly given comparison here is the way SSH works, but that is not comparing oranges to oranges. With SSH you also have some authentication credentials that have been given to you via another channel, with a self-sign certificate you do not. You can emulate SSH's "remember this servers ket fingerprint and only tell me if it has changed" in most browsers by adding a permanent exception, so it'll only moan again if the self-signed certificate changes. Firefox does this.

  Having a CA signed cert proves nothing beyond that you gave some person who is trusted some amount of money who ostensibly verified something.
That is true, but having a self-signed cert proves nothing at all. There is some process (a process that has been shown to have exploitable flaws I'll grant you, but a process exists and is far from completely broken) to try make sure that the CAs that are generally trusted are generally trustworthy.

  Renewals which exist as a pure profit vehicle for CAs
Renewals exist because certificates expire. Certificates expire because an infinitely valid certificate is potentially dangerous because the revokation process can not be relied upon in many cases.

  ... for something so much as an expiration date ...
  Gee, that's a nice commerce website you have there, would be a shame if something were to happen ...
If your e-commerce site finds $7/year or the hassle of using StartSSL's interface for free (or $120/y or $70/y respectively for EV certs) a problem, then it isn't much of a profit making e-commerce site...

  Charging to regenerate or revoke a certificate is just rent-seeking dick behavior                               
I'll say again: keep secure copies of the relevant keys and you won't need to use the regeneration or revocation procedures.

  again, completely automated processes with zero human interaction required                                    
Automated processes that rely on infrastructure that someone needs to create, monitor, and maintain. If you ignore the infrastructure creation and maintainance costs then yes the process is zero effort and near zero cost (just a little electricity for the CPU time) but ignoring those factors is simply fallacious reasoning.

If you so strongly believe that this is a complete and utter rip-off and that you could do it so much cheaper, why not do so? If you can do it as well while charging less (or nothing) then people will flock to your service. One man's margin is another's opportunity.

  Why do I have to pay upwards of $100 for a wildcard certificate? They don't cost the CA anymore to issue or handle
That I'll grant you, but artificial market segmentation exists everywhere for better or worse (usually for worse from the consumer's PoV) rather than being a property of this particular area.

  All so people who visit my website don't get scary and misleading warnings.                                 
The scary warnings are not misleading in the worse cases. If a DNS hijack passes your bank's traffic through a server that has a self-signed certificate would you want your browser to warn you or just carry on because self-signed certificates are fine usually? Unfortunately there is no way to differentiate the bad and fine situations so we give the scary warning for both to make sure we give it when it is really needed.

If you can think of a better way then do let people know, everyone in the know knows the current arrangement way isn't perfect so a good idea well presented should get listened too if addequately explored and explained.

If what you are looking for when you refer to "people visitin my website" is simple anti-snooping protection (so random people on the same WAN can't see everything for instance) rather than identity assurance, then there are already moves in that direction. HTTP2, due to be submitted for approval in final form later this year, will use encrypted traffic in all cases in a way the ensures this level of protection (though I've not yet read into the details of these proposals myself, I'll reserve judgement on how effective that will be until I have) meaning that is soon to become a sorted problem if things work out as expected. For e-commerce or anywhere else where greater trust is required though, a CA-signed certificate will still be required because for those uses identity assurance is essential.


>You can emulate SSH's "remember this servers ket fingerprint and only tell me if it has changed" in most browsers by adding a permanent exception, so it'll only moan again if the self-signed certificate changes. Firefox does this.

Doing this en-masse would be a much better system than we have right now. Example: Have a random internet user visit a site and note down the details of the certificate they get (automatically). Repeat a few thousand times. Compare notes. Wait a sec, why do I have a different certificate than 99% of the other visitors? Hmm. Throw alerts.

The chances of the average user being the target of a MITM is utterly minuscule, so this system ensures that you as the bad guy either have to own the service provider directly by installing a certificate you have keys for, or every single user that hits the site simultaneously to prevent the others from being alerted.

Pinning on steroids, basically. No CA's required.

>but having a self-signed cert proves nothing at all.

..other than the connection being encrypted, the CN on the cert matching the domain name, and it not being expired. This is the same data that the lowest level certificates from every CA provides.

I believe that the past decade or so has shown that CAs do not deserve the level of trust they're implicitly given. I certainly don't trust them. We know they can be coerced by the bad guys with guns to generate certs anyways. QED, they are not trustworthy.

>Renewals exist because certificates expire. Certificates expire because an infinitely valid certificate is potentially dangerous because the revokation process can not be relied upon in many cases.

Then re-generate the bloody certificate and don't charge me money for the privilege of giving me exactly what I had before with a different date on it!

>f your e-commerce site finds $7/year or the hassle of using StartSSL's interface for free (or $120/y or $70/y respectively for EV certs) a problem, then it isn't much of a profit making e-commerce site...

Ah yes, the old "It's not that expensive, so why are you complaining?" canard. A dime here, a nickel there. It's nothing.

Why just a little of a bad thing remains bad is left as an exercise to the reader.

>Automated processes that rely on infrastructure that someone needs to create, monitor, and maintain. If you so strongly believe that this is a complete and utter rip-off and that you could do it so much cheaper, why not do so? If you can do it as well while charging less (or nothing) then people will flock to your service. One man's margin is another's opportunity.

Why are there no serious community CAs? Why is every single one of them a large corporation? Larger infrastructure projects exist that are community, free/donationware efforts, after all. Is it really that hard, or is there some other reason?

I'll wager that one of the reasons is that entrenched players (the VeriSigns and Comodos and Thawtes of the world) get to set the standard for the market. For audits (e.g. Webtrust) that cost tens-to-hundreds of thousands of dollars to complete.

De-facto regulatory capture, except the regulations are more of a consensus than top-down legislating.

>The scary warnings are not misleading in the worse cases. If a DNS hijack passes your bank's traffic through a server that has a self-signed certificate would you want your browser to warn you or just carry on because self-signed certificates are fine usually?

I have no way to prove this, but I would be willing to bet large and ridiculous amounts of money that 99 out of 100 SSL warnings an average computer user sees is going to be the result of either misconfiguration (a badly set CN is common) or expiration. The connection is still encrypted and the certificate was still generated by a "trusted" CA so we know that the identity is valid (what are the chances that the owner of bar.com doesn't know of the existence of foo.bar.com?) - yet we still cry wolf like something is very definitely wrong.

And I say "cry wolf" for a reason. With the majority of SSL warnings being bogus (bogus as in they fail part of some validation test, instead of bogus as in the user was in some actual danger), we're training users to override the annoying warning every time.

And you can't override parts of the validation - it's all or nothing. If I know a certain website has an expired cert, and everything else is still valid, why can't I just override the expiration check? Being N+1 days out of date doesn't reduce the security of anyone concerned. - Instead I have to completely except the cert from all checks and then I won't get warned if say, the issuer changes or the CN doesn't match or some other data point, which when taken together, might add up to a different whole.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: