6 ms·

1. The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. 2. There is

1. The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. 2. There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message which will make them think there are security issued with your website. 3. Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure". 4. The culture of fear around HTTPS, meaning only the "most secure" or "newest" protocols and cipher suites are to be used. This prevents older clients from working, where HTTP works just fine. 5. HTTPS is needlessly complex making it hard to implement. There have been several security vulnerabilities introduced simply by its use. 6. If you can't comply with the OpenSSL license, implementing it yourself is a hopeless endevour. SSL was developed by corporations, for corporations. If you want some security feature to be applicable to the wider Internet, it needs to be community driven and community focused. Logging in to my server over SSH has far more security implications than accessing the website running on it over HTTPS. Yet, somehow, we managed to get SSH out there and accepted by the community without the need for Certificate Authorities.

pixl97 7y ago
Um, the number of people connected to my ssh server I can count on my fingers, and generally have communicated with beforehand. The number of people communicating with my https server is one larger than I could ever count to monitonically. If you dont get the difference in scale between the two you might have an issue understanding the real problem.
xvector 7y ago
> The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. Genuinely curious - what alternatives do you have in mind? Are there any WoT models that interest you more? > There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message Isn't this the point? > Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure". Could you elaborate? Have you written your whole stack from scratch? You are running millions of lines of code that you will never read but have been implemented by other parties. > HTTPS is needlessly complex making it hard to implement. Isn't this done with robust battle-tested libraries and built-in support in modern languages? --- Mainly I'm just wondering why you're letting perfect be the enemy of good. There's always room for improvement in everything, but I don't think user privacy is a reasonable sacrifice to make. > Giving in ends the hope that it will ever get changed. Abstaining from HTTPS won't be seen by anyone as a protest, but as incompetency, whether you find that justifiable or not.
- tooMuchCensor 7y ago
  Incompetency could be it. My website was down for a weekend, a thousand people got a dead website. I imagine if anyone other than a nerd was running our non profit website, if they'd always have the warning message.
- jart 7y ago
  DNSSEC is superior to both PKI and WOT. It's basically free. It makes chains of accountability transparent (hint: it's the dots in the URL). It provides the benefits of hierarchical trust except with democratic control, and is operated on film in public ceremonies. We don't have a robust understanding of who exactly operates PKI, but we do know that it's de facto governed by a company on Charleston Road, since CAs only have their root keys listed in things like web browsers at their pleasure. We also know that Charleston Road rewards CAs for their loyalty by red-zoning and down-ranking the folks who don't buy their products. Products which should ideally be deprecated, since SSL with PKI is much less secure. Can anyone guess who's stymied progress in Internet security, by knuckle-dragging on DNSSEC interoperation? It reminds me of the days of Microsoft refusing to implement W3C standards. Shame on you, folks who work on Charleston Road and don't speak up. You can dominate the Internet all you like, but at least let it be free at its foundation.
  - tptacek 7y ago
    Who's knuckle-dragging on DNSSEC interop? The entire Internet community. It's been almost 25 years, and 3 major revisions of the protocol, and still it has almost no adoption --- virtually none of the most commonly queried zones are signed. Why is that? Because DNSSEC is awful. Obviously, you can't replace "SSL with PKI" (you mean TLS, and/or the WebPKI) with DNSSEC, because DNSSEC doesn't encrypt anything. Whether or not you enact the ritual of adding signature records to your DNS zone, you will still need the TLS protocol to actually do anything securely, and the TLS protocol will still not need the DNS in order to authenticate connections. Instead, what DNSSEC (DANE, really) hopes to do is replace LetsEncrypt, which is not "basically" but instead "actually" free, with CAs run by TLD owners. Who owns the most important TLDs on the Internet? The Five Eyes governments and China. Good plan!
reaperducer 7y ago
4. The culture of fear around HTTPS, meaning only the "most secure" or "newest" protocols and cipher suites are to be used. This prevents older clients from working, where HTTP works just fine. This is important. I have several devices at home that cannot display many web sites because they don't have the ability to use latest ciphers.
- driverdan 7y ago
  Don't buy computing devices that don't give you root.
  - reaperducer 7y ago
    Rooting won't help most of these devices. They just don't have the horsepower. Moreover, they don't run Linux.
    - vunie 7y ago
      > Rooting won't help most of these devices. They just don't have the horsepower. If a device can "display" webpages then it's extremely likely that it can handle tls. > Moreover, they don't run Linux That has never stopped people before.
slim 7y ago
7. it breaks caching proxies
- Mikhail_Edoshin 7y ago
  I remember a discussion here on HN about how it makes life very hard for organizations like a school in Africa where the Internet connection is slow and expensive. Although many requests go many times to same pages (e.g. Wikipedia), HTTPS makes it impossible to cache them with a local cheap proxy. HTTPS is cargo-cult'ish in this aspect. One obviously should not accept or serve personal data over HTTP, but why to encrypt public information? (Having said that I'm guilty here too as I blindly followed the instruction given to me by my hosting company and my plain open site redirects to HTTPS.)
  - namibj 7y ago
    Soon we can properly sign HTTP requests using DNS for the PKI. Stuff like SRI inside HTML is paving the road to allow verification of hashes transmitted via header for the main page request, including a signature of that hash and url or such. Sort of similar to how linux package managers employ GPG and package mirrors. Or maybe we can provide caching based on signed-exchange.
  - rogual 7y ago
    One benefit of encrypting public information is that ISPs can't mess with it by inserting ads and such.
snowwrestler 7y ago
> The requirement to involve a 3rd party certificate authority is a needless power grab. TLS is public key encryption... a 3rd party attesting to the provenance of public keys is inherent to its design.

pixl97 7y ago

Um, the number of people connected to my ssh server I can count on my fingers, and generally have communicated with beforehand. The number of people communicating with my https server is one larger than I could ever count to monitonically. If you dont get the difference in scale between the two you might have an issue understanding the real problem.

xvector 7y ago

> The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. Genuinely curious - what alternatives do you have in mind? Are there any WoT models that interest you more? > There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message Isn't this the point? > Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure". Could you elaborate? Have you written your whole stack from scratch? You are running millions of lines of code that you will never read but have been implemented by other parties. > HTTPS is needlessly complex making it hard to implement. Isn't this done with robust battle-tested libraries and built-in support in modern languages? --- Mainly I'm just wondering why you're letting perfect be the enemy of good. There's always room for improvement in everything, but I don't think user privacy is a reasonable sacrifice to make. > Giving in ends the hope that it will ever get changed. Abstaining from HTTPS won't be seen by anyone as a protest, but as incompetency, whether you find that justifiable or not.

tooMuchCensor 7y ago
Incompetency could be it. My website was down for a weekend, a thousand people got a dead website. I imagine if anyone other than a nerd was running our non profit website, if they'd always have the warning message.
jart 7y ago
DNSSEC is superior to both PKI and WOT. It's basically free. It makes chains of accountability transparent (hint: it's the dots in the URL). It provides the benefits of hierarchical trust except with democratic control, and is operated on film in public ceremonies. We don't have a robust understanding of who exactly operates PKI, but we do know that it's de facto governed by a company on Charleston Road, since CAs only have their root keys listed in things like web browsers at their pleasure. We also know that Charleston Road rewards CAs for their loyalty by red-zoning and down-ranking the folks who don't buy their products. Products which should ideally be deprecated, since SSL with PKI is much less secure. Can anyone guess who's stymied progress in Internet security, by knuckle-dragging on DNSSEC interoperation? It reminds me of the days of Microsoft refusing to implement W3C standards. Shame on you, folks who work on Charleston Road and don't speak up. You can dominate the Internet all you like, but at least let it be free at its foundation.
- tptacek 7y ago
  Who's knuckle-dragging on DNSSEC interop? The entire Internet community. It's been almost 25 years, and 3 major revisions of the protocol, and still it has almost no adoption --- virtually none of the most commonly queried zones are signed. Why is that? Because DNSSEC is awful. Obviously, you can't replace "SSL with PKI" (you mean TLS, and/or the WebPKI) with DNSSEC, because DNSSEC doesn't encrypt anything. Whether or not you enact the ritual of adding signature records to your DNS zone, you will still need the TLS protocol to actually do anything securely, and the TLS protocol will still not need the DNS in order to authenticate connections. Instead, what DNSSEC (DANE, really) hopes to do is replace LetsEncrypt, which is not "basically" but instead "actually" free, with CAs run by TLD owners. Who owns the most important TLDs on the Internet? The Five Eyes governments and China. Good plan!

reaperducer 7y ago

4. The culture of fear around HTTPS, meaning only the "most secure" or "newest" protocols and cipher suites are to be used. This prevents older clients from working, where HTTP works just fine. This is important. I have several devices at home that cannot display many web sites because they don't have the ability to use latest ciphers.

driverdan 7y ago
Don't buy computing devices that don't give you root.
- reaperducer 7y ago
  Rooting won't help most of these devices. They just don't have the horsepower. Moreover, they don't run Linux.
  - vunie 7y ago
    > Rooting won't help most of these devices. They just don't have the horsepower. If a device can "display" webpages then it's extremely likely that it can handle tls. > Moreover, they don't run Linux That has never stopped people before.

slim 7y ago

7. it breaks caching proxies

Mikhail_Edoshin 7y ago
I remember a discussion here on HN about how it makes life very hard for organizations like a school in Africa where the Internet connection is slow and expensive. Although many requests go many times to same pages (e.g. Wikipedia), HTTPS makes it impossible to cache them with a local cheap proxy. HTTPS is cargo-cult'ish in this aspect. One obviously should not accept or serve personal data over HTTP, but why to encrypt public information? (Having said that I'm guilty here too as I blindly followed the instruction given to me by my hosting company and my plain open site redirects to HTTPS.)
- namibj 7y ago
  Soon we can properly sign HTTP requests using DNS for the PKI. Stuff like SRI inside HTML is paving the road to allow verification of hashes transmitted via header for the main page request, including a signature of that hash and url or such. Sort of similar to how linux package managers employ GPG and package mirrors. Or maybe we can provide caching based on signed-exchange.
- rogual 7y ago
  One benefit of encrypting public information is that ISPs can't mess with it by inserting ads and such.

snowwrestler 7y ago

> The requirement to involve a 3rd party certificate authority is a needless power grab. TLS is public key encryption... a 3rd party attesting to the provenance of public keys is inherent to its design.