8 ms·

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustl

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

couchand 7y ago
One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.
- dm33tri 7y ago
  You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.
  - zozbot234 7y ago
    The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.
- deleted 7y ago
  [deleted]
- JackRabbitSlim 7y ago
  Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.
  - arminiusreturns 7y ago
    Yep, for years when everyone was talking about NSL's and other corporate strong-arming by the gov, I started saying I suspect most major CA's are compromised. At least you know your threat model though, because only the nation states are going to have that. CA's and DNS are two parts of the internet that have become way too centralized in my opinion.
  - daxelrod 7y ago
    This is one of the threats addressed by https://www.certificate-transparency.org/ https://www.certificate-transparency.org/ . If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect. If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.
zozbot234 7y ago
Do they? IME, they just ask you if you want to trust the self-signed certificate and allow you to optionally store that "trust" indefinitely, ending up with something like Trust On First Use. The warnings have to be scary initially because the security model is so radically different from the usual case of CA's; specifically, getting that "first use" validation correct is critically important.
- dm33tri 7y ago
  They show big red error and prompt to continue is hidden under spoiler. Also XHR requests just cut off, it's painful when developing and testing.
  - zozbot234 7y ago
    Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.
    - namibj 7y ago
      The XHR api could allow specifying a trust root and/or cert-pinning though.
      - edoceo 7y ago
        It already does, put your self-CA in the browser trust store.
      - necovek 7y ago
        How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks. For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).
heydabop 7y ago
> then I have go through all that hustle to make it work So like 3-5 minutes of work with Let's Encrypt?
cesarb 7y ago
Since there's no way to distinguish a non-verified (self-signed or not) certificate from an attack, browsers have to treat them identically to an attack (otherwise an attacker would simply pretend to be a non-verified certificate, to get the more lenient treatment). On the other hand, a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted.
- deleted 7y ago
  [deleted]
- lucideer 7y ago
  I think the point here is that there's also no way to distinguish a http request from an attack. It's fair enough to an argue that a self-signed cert could be an attack, but so could any http request. > a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted. I don't understand how that allows one to distinguish it from an attack. Knowing that a connection is supposed to be unencrypted is just equivalent to knowing that a connection could be under attack.
  - knome 7y ago
    Rightly punishing the connection for having the trappings of security when it actually lacks it doesn't mean we need to punish openly insecure traffic. End users have been told time and again that http is insecure, and so it's fine to leave it. End users should also be able to trust that https means secure without having to distinguish between secure and secure unless I'm being mitm'd and needing to understand what any of that means.
    - mrob 7y ago
      Most end users have no idea what HTTPS is. They've just been (incorrectly) taught that the padlock means it's secure. Disable the padlock for self-signed HTTPS, and disable the CA-signed HTTPS-only features, and it becomes strictly better than HTTP.
UI_at_80x24 7y ago
>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee you haven't even tried.
- zamadatix 7y ago
  You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!
  - giancarlostoro 7y ago
    To be reasonably fair Lets Encrypt makes it easy. I even have a $5 a year shared hosting account that gives me Lets Encrypt SSL certs through cpanel. I can't imagine this feature is unique only to this one random shared hosting provider.
    - fishtacos 7y ago
      Your $5 instance with cPanel management isn't really quite the same as someone manually managing 100 servers hosting these services on disparate configurations and environments. In other words, what your tooling of choice automates in a specific situation doesn't necessarily apply to any one else's usage, and scalability-wise, would be even more detached.
      - giancarlostoro 7y ago
        Certbot works with multiple configurations and servers / Operating Systems: https://certbot.eff.org/ https://certbot.eff.org/ I wouldn't be surprised if that's how he's managing 100 servers, or something similar.
JoshTriplett 7y ago
> Why do browsers punish non-verified certs much harder than no-cert? Because it's taking time to build enough acceptance to flag http as insecure, whereas bad https connections that can't guarantee the expected security properties have been flagged as insecure from the beginning. At this point, though, modern browsers show http sites as various flavors of "not secure" in the address bar, and limit what those sites can do. Browsers will increase the restrictions on insecure http over time, and hopefully get to the point where insecure http outside the local network gets treated much like bad https.
notatoad 7y ago
because warning fatigue is real and http usage is too high to put scary warnings on all those sites. Chrome's eventual goal is to mark all not-secure pages as not-secure: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
- umvi 7y ago
  > because warning fatigue is real "HTTP is known to cause cancer in the state of California"
Thorrez 7y ago
A non-verified cert can steal Secure cookies, no-cert cannot.

couchand 7y ago

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

dm33tri 7y ago
You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.
- zozbot234 7y ago
  The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.
deleted 7y ago
[deleted]
JackRabbitSlim 7y ago
Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.
- arminiusreturns 7y ago
  Yep, for years when everyone was talking about NSL's and other corporate strong-arming by the gov, I started saying I suspect most major CA's are compromised. At least you know your threat model though, because only the nation states are going to have that. CA's and DNS are two parts of the internet that have become way too centralized in my opinion.
- daxelrod 7y ago
  This is one of the threats addressed by https://www.certificate-transparency.org/ https://www.certificate-transparency.org/ . If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect. If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.

zozbot234 7y ago

Do they? IME, they just ask you if you want to trust the self-signed certificate and allow you to optionally store that "trust" indefinitely, ending up with something like Trust On First Use. The warnings have to be scary initially because the security model is so radically different from the usual case of CA's; specifically, getting that "first use" validation correct is critically important.

dm33tri 7y ago
They show big red error and prompt to continue is hidden under spoiler. Also XHR requests just cut off, it's painful when developing and testing.
- zozbot234 7y ago
  Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.
  - namibj 7y ago
    The XHR api could allow specifying a trust root and/or cert-pinning though.
    - edoceo 7y ago
      It already does, put your self-CA in the browser trust store.
    - necovek 7y ago
      How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks. For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).

heydabop 7y ago

> then I have go through all that hustle to make it work So like 3-5 minutes of work with Let's Encrypt?

cesarb 7y ago

Since there's no way to distinguish a non-verified (self-signed or not) certificate from an attack, browsers have to treat them identically to an attack (otherwise an attacker would simply pretend to be a non-verified certificate, to get the more lenient treatment). On the other hand, a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted.

deleted 7y ago
[deleted]
lucideer 7y ago
I think the point here is that there's also no way to distinguish a http request from an attack. It's fair enough to an argue that a self-signed cert could be an attack, but so could any http request. > a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted. I don't understand how that allows one to distinguish it from an attack. Knowing that a connection is supposed to be unencrypted is just equivalent to knowing that a connection could be under attack.
- knome 7y ago
  Rightly punishing the connection for having the trappings of security when it actually lacks it doesn't mean we need to punish openly insecure traffic. End users have been told time and again that http is insecure, and so it's fine to leave it. End users should also be able to trust that https means secure without having to distinguish between secure and secure unless I'm being mitm'd and needing to understand what any of that means.
  - mrob 7y ago
    Most end users have no idea what HTTPS is. They've just been (incorrectly) taught that the padlock means it's secure. Disable the padlock for self-signed HTTPS, and disable the CA-signed HTTPS-only features, and it becomes strictly better than HTTP.

UI_at_80x24 7y ago

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee you haven't even tried.

zamadatix 7y ago
You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!
- giancarlostoro 7y ago
  To be reasonably fair Lets Encrypt makes it easy. I even have a $5 a year shared hosting account that gives me Lets Encrypt SSL certs through cpanel. I can't imagine this feature is unique only to this one random shared hosting provider.
  - fishtacos 7y ago
    Your $5 instance with cPanel management isn't really quite the same as someone manually managing 100 servers hosting these services on disparate configurations and environments. In other words, what your tooling of choice automates in a specific situation doesn't necessarily apply to any one else's usage, and scalability-wise, would be even more detached.
    - giancarlostoro 7y ago
      Certbot works with multiple configurations and servers / Operating Systems: https://certbot.eff.org/ https://certbot.eff.org/ I wouldn't be surprised if that's how he's managing 100 servers, or something similar.

JoshTriplett 7y ago

> Why do browsers punish non-verified certs much harder than no-cert? Because it's taking time to build enough acceptance to flag http as insecure, whereas bad https connections that can't guarantee the expected security properties have been flagged as insecure from the beginning. At this point, though, modern browsers show http sites as various flavors of "not secure" in the address bar, and limit what those sites can do. Browsers will increase the restrictions on insecure http over time, and hopefully get to the point where insecure http outside the local network gets treated much like bad https.

notatoad 7y ago

because warning fatigue is real and http usage is too high to put scary warnings on all those sites. Chrome's eventual goal is to mark all not-secure pages as not-secure: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...

umvi 7y ago
> because warning fatigue is real "HTTP is known to cause cancer in the state of California"

Thorrez 7y ago

A non-verified cert can steal Secure cookies, no-cert cannot.