8 ms·

It was a huge mistake to have browsers treat an expired cert with so much force. An expired cert website is at the least, just as good as a http site and yet en

It was a huge mistake to have browsers treat an expired cert with so much force. An expired cert website is at the least, just as good as a http site and yet entirely unencrypted sites see a few warnings on login forms while expired cert sites are unaccessable.

joering2 5y ago
Its worst than that. Google chrome doesn't like more sites than others. On most you can simply click "proceed to danger" and ignore missing cert. On some other like cryptome, they don't even give you option to continue. https://cryptome.org/ https://cryptome.org/
- judge2020 5y ago
  This is generally enforced by HSTS - one of the features is that, if the site has it enabled and the site has a TLS-related error, the browsers prevent users from bypassing the SSL error screen (at least, without typing `thisisunsafe` in chrome). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St... https://security.stackexchange.com/q/195688/96942 https://security.stackexchange.com/q/195688/96942
- weedfroglozenge 5y ago
  I'm glad I saw this comment - What can make a site perform like that? At work we use Chrome as our general browser, and we've had several issues with expired certs before. Some websites allowed you to expand the box and opt "Continue" but some simply didn't have the option. Whats the difference?
  - eropple 5y ago
    Sites can opt into "do not let somebody continue if the cert is bad" via HSTS.
  - bmcahren 5y ago
    HTTP Strict Transport Security (HSTS) is enabled at the DNS level which tells modern browsers "I'm a modern website and want to only be served on valid certificates, otherwise refuse to allow access to my website because something must be very wrong for this to happen". The assumption is "must be very wrong" is an attack you don't want people to "continue" past. Occasionally it bites back like this if you don't maintain your certificates. Offering HTTP transport invites attackers to inject advertisements, malware, or viruses into your packet stream. ISP like comcast and ATT are notorious for doing this. Allowing falsified or expired certificates invites attackers as well. HTST This is a good thing.
    - Dylan16807 5y ago
      DNS? You announce it with a header or get on the preload list. I don't think there's a DNS method.
      - dagenix 5y ago
        Yeah, there is no DNS mechanism. Although, IIRC, it is possible to place an entire TLD on the preload list - which still doesn't use DNS, but its a mechanism to enable HSTS where the website itself doesn't do anything.
- oefrha 5y ago
  Like others said, the site is using HSTS: > curl -sSk -D- https://cryptome.org/ -o /dev/null | grep strict-transport-security strict-transport-security: max-age=31536000 But even then, Chrome 91 on both macOS and Windows totally does allow me to Proceed to cryptome.org (unsafe) Maybe it's only offered because I never visited the site in the past?
- gfody 5y ago
  Firefox 88 here, cryptome.org loads with a red exclamation warning icon in the address bar, w3.org refuses to load and when I click on "advanced" there is not even an "accept risk and continue" option. I don't even know how to load w3.org right now if I had to.
est31 5y ago
Maybe there should be a "warned from" extension for certificates, which contains a date within the validity period from which on user agents are supposed to display warnings?
- selcuka 5y ago
  I believe the "Not Valid After" field should be used as a "Warn for x days after this date" value where x is a small value (such as 3).
  - akerl_ 5y ago
    Why? The date says “Not valid after”, and the site operator can monitor it, or just set a calendar invite when it’s issued. Making the “real” expiration some arbitrary number of days after the marked expiration date seems like it’s unlikely to modify cert owner behaviors, but it does make validation way more complicated for browsers.
    - selcuka 5y ago
      I agree, but it is also overkill to display a warning page saying that "you are in danger" just because the certificate expired today. There should be a middle ground.
      - akerl_ 5y ago
        Why? There’s already a clear better option: teams that run HTTPS sites need to monitor for cert expiry. It’s the easiest outage to avoid because the moment the cert is generated, you know the exact time it will expire.
        selcuka 5y ago
        Yes,it's a better option for the site admins. It doesn't help the consumer though. Imagine you can't use your banking site because the certificate expired a few minutes ago and the browser displays a (unnecessarily dramatic) error message. Not everyone is tech savvy enough to ignore those messages. The browsers already let you visit the site if you want to, so I don't think there is a big deal.
Rapzid 5y ago
Chrome wasn't even giving me the option to proceed, something about HSTS.. Unsure I just know the option was not there.
- Wowfunhappy 5y ago
  It will let you in if you type `thisisunsafe`.
  - peterburkimsher 5y ago
    Nice tip! I tried that, but then the company firewall blocked it for the same reason. (zscaler Access denied due to bad server certificate)
- sp332 5y ago
  Right, the website can opt-in to requiring TLS for connections. Browsers can choose to honor this and disallow all plain HTTP connections... and all TLS connections with "invalid" certificates. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security It's a great way for site admins to turn a minor certificate issue into a complete disaster :(
  - charrondev 5y ago
    If you don’t use HSTS you open your users up to downgrade attacks. https://auth0.com/blog/preventing-https-downgrade-attacks/ https://auth0.com/blog/preventing-https-downgrade-attacks/
- dilyevsky 5y ago
  That’s the whole point of hsts. Won’t work on safari either. I don’t use chrome and won’t recommend it but if you have to view it you can clear hsts for that domain in chrome://settings
  - Rapzid 5y ago
    The point is taking the option away from users to proceed if there is a cert issue? Really it's not.
dilyevsky 5y ago
The reason if something is http only they dgaf about security. If I choose (or redirected to) https and it doesn’t work it might be an attack
superkuh 5y ago
The greater mistake isn't being perpetrated by the big browser companies scaremongering bad certs. The fault lies with every sysadmin or web dev that choses to 301 redirect from HTTP to HTTPS and not have HTTP+HTTPS. You can do your part to make this a non-problem by always serving HTTP and HTTPS both.
- eru 5y ago
  What's HTTP+HTTPS?
  - posixplz 5y ago
    Serve the same content over HTTP and HTTPS. Many web admins today don’t serve content over http, instead they HTTP/301 redirect all http requests to https.
- bawolff 5y ago
  And i guess you think TLS-stripping attacks are unimportant?
  - superkuh 5y ago
    For many sites, and probably most non-commercial sites, yes. Anyone thinking about this issue can decide if that threat model applies to them: do they even have a log in, or is it just html files and jpegs in directories? etc.
    - raggi 5y ago
      How do you determine a users privacy requirements by site alone? The content does not imply relevance to privacy abuse; abusers come in all manners and may take abusive objection to content like w3.org that would to most people seem innocuous.
      - superkuh 5y ago
        It's pretty easy when you are the person that made the website (like most personal websites). Again, I am not advocating for not having HTTPS so I don't know why you think HTTP+HTTPS is less private. It is exactly as private only it is also human readable and requires no centralized authority's lease to be visitable.
bawolff 5y ago
It all depends on context and browsers have to have defaults that work for every context. Sure a recently expired cert is pronably the least severe issue a tls cert can have, but still - expired certs that are compromised usually aren't revoked. If i'm visiting my bank, i definitely want things to err on the side of not working.
- rabidrat 5y ago
  It's the combination of defaults that's problematic. If the site requires https, because it's e.g. a bank, then sure, require non-expired cert. But my static sites which have no auth, payment, or even subpages (path-obscuration being another of the touted benefits of https-everywhere), do not require https. Except because of the defaults Google's overzealous security team decided to inflict on the world, now I have to have a process that reaches out to LE every 3 months. For a static website which otherwise never needs updating.
  - deleted 5y ago
    [deleted]
  - nine_k 5y ago
    Serve it both on ports 80 and 443.
  - bawolff 5y ago
    Well according to others on this thread, w3.org enabled HSTS - so they specificly opted into strict mode. They were not using the defaults. So that criticism does not apply here.
  - SilverRed 5y ago
    >now I have to have a process that reaches out to LE every 3 months. This is not particularly hard. Most static hosting services even do it for you.
  - DenseComet 5y ago
    Https also ensures that the connection has not been tampered with by an ISP. Its quite stupid, especially considering you're paying them already, but used to be common when most of the web was http. Also, router malware has been seen injecting JS into http pages to mine crypto. https://www.infoworld.com/article/2925839/code-injection-new-low-isps.html https://www.infoworld.com/article/2925839/code-injection-new... https://www.privateinternetaccess.com/blog/comcast-still-uses-mitm-javascript-injection-serve-unwanted-ads-messages/ https://www.privateinternetaccess.com/blog/comcast-still-use... https://blog.avast.com/mikrotik-routers-targeted-by-cryptomining-campaign-avast https://blog.avast.com/mikrotik-routers-targeted-by-cryptomi...
barosl 5y ago
Actually, there are certain cases where visiting a site under an expired certificate is strictly more vulnerable than visiting a normal http site. Certain web features only work in a secure context[1], which an http site does not expose. Therefore, a hacker who can convince the user to accept their invalid certificate can extract more information from the user. Whether it was a good idea to limit those functionalities to a secure context or not, I don't know. I'm also a bit opposed to this forced HTTPS everywhere mentality. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
- Wowfunhappy 5y ago
  Seems to me, though, that the right solution would be to turn those features off as opposed to denying the whole site. (If the site relies on those features to work and breaks as a result, so be it.)
- KMag 5y ago
  Disabling these features for expired certificates and limiting secure cookies to a single session sounds reasonable as a "limp home" degraded functionality mode. Obviously one wouldn't want the padlock icon to be displayed in the address bar in this case.
0xbadcafebee 5y ago
Well from their perspective it was great. Why have an extra code path to worry about when you can just make the thing less useful? I tried to remove a specific cookie from my browser session recently. The only way is to go into Developer Tools, find what tab has "Storage", find the cookies, select the cookie you want, right click and delete it. You can't do it from the 4 other user-friendly screens that already show you the individual cookies, because why would a user ever want to delete an individual cookie? I think this is the same reason for all of the poor browser UX over the years, like personal certs. The web would be a lot more secure if personal certs had supplanted passwords 15 years ago. But then we'd have to build something other than a single pop-up box to manage them. Sure, we got a built-in password manager, and we suggest random passwords for users, and save them locally, and the user needs to back them up (or reset them via e-mail). But doing the same thing for certificates might be confusing, meaning, somebody would have to actually talk to a user (until it became common knowledge). Better to wait for something way more complicated and expensive to show up, and ignore UX there too. (https://security.stackexchange.com/questions/1430/is-anybody-using-client-browser-certificates https://security.stackexchange.com/questions/1430/is-anybody...)
- KMag 5y ago
  I totally agree w.r.t. password managers. Luckily, with browsers now having built-in password managers, it's less UI friction if we come up with some standard for user certificate workflow that's close to password workflow. In a world where users rarely see their actual passwords, it's much less of a UI change to (nearly) silently replace password changes with certificate signings and (nearly) silently replace password logins with certificate presentations. A small extra attribute in the HTML input tag could signal to the password manager that it should perform the certificate workflow instead of the password workflow. Ideally, instead of specifying a specific mechanism, the extra input tag attribute would signal the password manager to actually perform a SPNEGO mechanism negotiation, so the password manager and the server could negotiate if they were using certificates, Kerberos, or some future mechanism. Though, this would also require adding certificate support to GSSAPI. The upside would be that future changes could be done without any changes to HTML.
nine_k 5y ago
I wish browsers showed a large warning like "This site's TLS certificate EXPIRES IN FIVE DAYS", or something. It would be less shameful to have it than an expired certificate. But most of all, anyone handling the site would have an advance warning, instead of a catastrophic failure. This would lower the number of actual expirations significantly.
- jraph 5y ago
  It would be terrible for visitors who have no clue on what a certificate is, or even what HTTP is. It could be scary for them, they could even think they were "hacked".
- KMag 5y ago
  I think that a bunch of things like the JavaScript console, DOM editor, etc. should only be enabled when a browser developer mode has been activated, and such a mode would also enable a variety of warnings like this. It shouldn't be difficult to find or enable the developer mode, but it shouldn't be on by default. That way, people who know (or should know) what these sorts of warnings mean will see them without ordinary users getting unnecessarily scared or confused. Hopefully a site's own developers regularly view their own site in the same browser they've used in the past for debugging the site.
- hakre 5y ago
  a certificate is either valid or its not. this is more for administering it or for users that rely on it and want to know within build systems, at least that is where it did hit me. the failure then, the same. wondered although if there is some use in knowing an upcoming expiration. # curl + GNU date + GNU grep -P $ echo "cert days left: ~$(( ($(date +%s -d "$(curl -IvsS https://www.w3.org 2>&1 >/dev/null | grep -Po '(?<=^\* expire date: ).*')")-$(date +%s))/86400 ))" cert days left: ~396 but then what should the information give? that my build breaks, say next Tuesday? and what if until then the certificate expiration is enlarged?
indolering 5y ago
No, it was a mistake not to implement everything in DNS ... since that is what cryptographically determines ownership of a domain anyway. Any other certificate mechanism is just middle men selling snake oil and causing additional administrative overhead.
stjohnswarts 5y ago
I can't agree. It should be enforced with extreme prejudice. Some people's lives may depend on it.
- SilverRed 5y ago
  And their lives depend less when the site uses no certificate at all?
deleted 5y ago
[deleted]

joering2 5y ago

Its worst than that. Google chrome doesn't like more sites than others. On most you can simply click "proceed to danger" and ignore missing cert. On some other like cryptome, they don't even give you option to continue. https://cryptome.org/ https://cryptome.org/

judge2020 5y ago
This is generally enforced by HSTS - one of the features is that, if the site has it enabled and the site has a TLS-related error, the browsers prevent users from bypassing the SSL error screen (at least, without typing `thisisunsafe` in chrome). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St... https://security.stackexchange.com/q/195688/96942 https://security.stackexchange.com/q/195688/96942
weedfroglozenge 5y ago
I'm glad I saw this comment - What can make a site perform like that? At work we use Chrome as our general browser, and we've had several issues with expired certs before. Some websites allowed you to expand the box and opt "Continue" but some simply didn't have the option. Whats the difference?
- eropple 5y ago
  Sites can opt into "do not let somebody continue if the cert is bad" via HSTS.
- bmcahren 5y ago
  HTTP Strict Transport Security (HSTS) is enabled at the DNS level which tells modern browsers "I'm a modern website and want to only be served on valid certificates, otherwise refuse to allow access to my website because something must be very wrong for this to happen". The assumption is "must be very wrong" is an attack you don't want people to "continue" past. Occasionally it bites back like this if you don't maintain your certificates. Offering HTTP transport invites attackers to inject advertisements, malware, or viruses into your packet stream. ISP like comcast and ATT are notorious for doing this. Allowing falsified or expired certificates invites attackers as well. HTST This is a good thing.
  - Dylan16807 5y ago
    DNS? You announce it with a header or get on the preload list. I don't think there's a DNS method.
    - dagenix 5y ago
      Yeah, there is no DNS mechanism. Although, IIRC, it is possible to place an entire TLD on the preload list - which still doesn't use DNS, but its a mechanism to enable HSTS where the website itself doesn't do anything.
oefrha 5y ago
Like others said, the site is using HSTS: > curl -sSk -D- https://cryptome.org/ -o /dev/null | grep strict-transport-security strict-transport-security: max-age=31536000 But even then, Chrome 91 on both macOS and Windows totally does allow me to Proceed to cryptome.org (unsafe) Maybe it's only offered because I never visited the site in the past?
gfody 5y ago
Firefox 88 here, cryptome.org loads with a red exclamation warning icon in the address bar, w3.org refuses to load and when I click on "advanced" there is not even an "accept risk and continue" option. I don't even know how to load w3.org right now if I had to.

est31 5y ago

Maybe there should be a "warned from" extension for certificates, which contains a date within the validity period from which on user agents are supposed to display warnings?

selcuka 5y ago
I believe the "Not Valid After" field should be used as a "Warn for x days after this date" value where x is a small value (such as 3).
- akerl_ 5y ago
  Why? The date says “Not valid after”, and the site operator can monitor it, or just set a calendar invite when it’s issued. Making the “real” expiration some arbitrary number of days after the marked expiration date seems like it’s unlikely to modify cert owner behaviors, but it does make validation way more complicated for browsers.
  - selcuka 5y ago
    I agree, but it is also overkill to display a warning page saying that "you are in danger" just because the certificate expired today. There should be a middle ground.
    - akerl_ 5y ago
      Why? There’s already a clear better option: teams that run HTTPS sites need to monitor for cert expiry. It’s the easiest outage to avoid because the moment the cert is generated, you know the exact time it will expire.
      - selcuka 5y ago
        Yes,it's a better option for the site admins. It doesn't help the consumer though. Imagine you can't use your banking site because the certificate expired a few minutes ago and the browser displays a (unnecessarily dramatic) error message. Not everyone is tech savvy enough to ignore those messages. The browsers already let you visit the site if you want to, so I don't think there is a big deal.

Rapzid 5y ago

Chrome wasn't even giving me the option to proceed, something about HSTS.. Unsure I just know the option was not there.

Wowfunhappy 5y ago
It will let you in if you type `thisisunsafe`.
- peterburkimsher 5y ago
  Nice tip! I tried that, but then the company firewall blocked it for the same reason. (zscaler Access denied due to bad server certificate)
sp332 5y ago
Right, the website can opt-in to requiring TLS for connections. Browsers can choose to honor this and disallow all plain HTTP connections... and all TLS connections with "invalid" certificates. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security It's a great way for site admins to turn a minor certificate issue into a complete disaster :(
- charrondev 5y ago
  If you don’t use HSTS you open your users up to downgrade attacks. https://auth0.com/blog/preventing-https-downgrade-attacks/ https://auth0.com/blog/preventing-https-downgrade-attacks/
dilyevsky 5y ago
That’s the whole point of hsts. Won’t work on safari either. I don’t use chrome and won’t recommend it but if you have to view it you can clear hsts for that domain in chrome://settings
- Rapzid 5y ago
  The point is taking the option away from users to proceed if there is a cert issue? Really it's not.

dilyevsky 5y ago

The reason if something is http only they dgaf about security. If I choose (or redirected to) https and it doesn’t work it might be an attack

superkuh 5y ago

The greater mistake isn't being perpetrated by the big browser companies scaremongering bad certs. The fault lies with every sysadmin or web dev that choses to 301 redirect from HTTP to HTTPS and not have HTTP+HTTPS. You can do your part to make this a non-problem by always serving HTTP and HTTPS both.

eru 5y ago
What's HTTP+HTTPS?
- posixplz 5y ago
  Serve the same content over HTTP and HTTPS. Many web admins today don’t serve content over http, instead they HTTP/301 redirect all http requests to https.
bawolff 5y ago
And i guess you think TLS-stripping attacks are unimportant?
- superkuh 5y ago
  For many sites, and probably most non-commercial sites, yes. Anyone thinking about this issue can decide if that threat model applies to them: do they even have a log in, or is it just html files and jpegs in directories? etc.
  - raggi 5y ago
    How do you determine a users privacy requirements by site alone? The content does not imply relevance to privacy abuse; abusers come in all manners and may take abusive objection to content like w3.org that would to most people seem innocuous.
    - superkuh 5y ago
      It's pretty easy when you are the person that made the website (like most personal websites). Again, I am not advocating for not having HTTPS so I don't know why you think HTTP+HTTPS is less private. It is exactly as private only it is also human readable and requires no centralized authority's lease to be visitable.

bawolff 5y ago

It all depends on context and browsers have to have defaults that work for every context. Sure a recently expired cert is pronably the least severe issue a tls cert can have, but still - expired certs that are compromised usually aren't revoked. If i'm visiting my bank, i definitely want things to err on the side of not working.

rabidrat 5y ago
It's the combination of defaults that's problematic. If the site requires https, because it's e.g. a bank, then sure, require non-expired cert. But my static sites which have no auth, payment, or even subpages (path-obscuration being another of the touted benefits of https-everywhere), do not require https. Except because of the defaults Google's overzealous security team decided to inflict on the world, now I have to have a process that reaches out to LE every 3 months. For a static website which otherwise never needs updating.
- deleted 5y ago
  [deleted]
- nine_k 5y ago
  Serve it both on ports 80 and 443.
- bawolff 5y ago
  Well according to others on this thread, w3.org enabled HSTS - so they specificly opted into strict mode. They were not using the defaults. So that criticism does not apply here.
- SilverRed 5y ago
  >now I have to have a process that reaches out to LE every 3 months. This is not particularly hard. Most static hosting services even do it for you.
- DenseComet 5y ago
  Https also ensures that the connection has not been tampered with by an ISP. Its quite stupid, especially considering you're paying them already, but used to be common when most of the web was http. Also, router malware has been seen injecting JS into http pages to mine crypto. https://www.infoworld.com/article/2925839/code-injection-new-low-isps.html https://www.infoworld.com/article/2925839/code-injection-new... https://www.privateinternetaccess.com/blog/comcast-still-uses-mitm-javascript-injection-serve-unwanted-ads-messages/ https://www.privateinternetaccess.com/blog/comcast-still-use... https://blog.avast.com/mikrotik-routers-targeted-by-cryptomining-campaign-avast https://blog.avast.com/mikrotik-routers-targeted-by-cryptomi...

barosl 5y ago

Actually, there are certain cases where visiting a site under an expired certificate is strictly more vulnerable than visiting a normal http site. Certain web features only work in a secure context[1], which an http site does not expose. Therefore, a hacker who can convince the user to accept their invalid certificate can extract more information from the user. Whether it was a good idea to limit those functionalities to a secure context or not, I don't know. I'm also a bit opposed to this forced HTTPS everywhere mentality. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

Wowfunhappy 5y ago
Seems to me, though, that the right solution would be to turn those features off as opposed to denying the whole site. (If the site relies on those features to work and breaks as a result, so be it.)
KMag 5y ago
Disabling these features for expired certificates and limiting secure cookies to a single session sounds reasonable as a "limp home" degraded functionality mode. Obviously one wouldn't want the padlock icon to be displayed in the address bar in this case.

0xbadcafebee 5y ago

Well from their perspective it was great. Why have an extra code path to worry about when you can just make the thing less useful? I tried to remove a specific cookie from my browser session recently. The only way is to go into Developer Tools, find what tab has "Storage", find the cookies, select the cookie you want, right click and delete it. You can't do it from the 4 other user-friendly screens that already show you the individual cookies, because why would a user ever want to delete an individual cookie? I think this is the same reason for all of the poor browser UX over the years, like personal certs. The web would be a lot more secure if personal certs had supplanted passwords 15 years ago. But then we'd have to build something other than a single pop-up box to manage them. Sure, we got a built-in password manager, and we suggest random passwords for users, and save them locally, and the user needs to back them up (or reset them via e-mail). But doing the same thing for certificates might be confusing, meaning, somebody would have to actually talk to a user (until it became common knowledge). Better to wait for something way more complicated and expensive to show up, and ignore UX there too. (https://security.stackexchange.com/questions/1430/is-anybody-using-client-browser-certificates https://security.stackexchange.com/questions/1430/is-anybody...)

KMag 5y ago
I totally agree w.r.t. password managers. Luckily, with browsers now having built-in password managers, it's less UI friction if we come up with some standard for user certificate workflow that's close to password workflow. In a world where users rarely see their actual passwords, it's much less of a UI change to (nearly) silently replace password changes with certificate signings and (nearly) silently replace password logins with certificate presentations. A small extra attribute in the HTML input tag could signal to the password manager that it should perform the certificate workflow instead of the password workflow. Ideally, instead of specifying a specific mechanism, the extra input tag attribute would signal the password manager to actually perform a SPNEGO mechanism negotiation, so the password manager and the server could negotiate if they were using certificates, Kerberos, or some future mechanism. Though, this would also require adding certificate support to GSSAPI. The upside would be that future changes could be done without any changes to HTML.

nine_k 5y ago

I wish browsers showed a large warning like "This site's TLS certificate EXPIRES IN FIVE DAYS", or something. It would be less shameful to have it than an expired certificate. But most of all, anyone handling the site would have an advance warning, instead of a catastrophic failure. This would lower the number of actual expirations significantly.

jraph 5y ago
It would be terrible for visitors who have no clue on what a certificate is, or even what HTTP is. It could be scary for them, they could even think they were "hacked".
KMag 5y ago
I think that a bunch of things like the JavaScript console, DOM editor, etc. should only be enabled when a browser developer mode has been activated, and such a mode would also enable a variety of warnings like this. It shouldn't be difficult to find or enable the developer mode, but it shouldn't be on by default. That way, people who know (or should know) what these sorts of warnings mean will see them without ordinary users getting unnecessarily scared or confused. Hopefully a site's own developers regularly view their own site in the same browser they've used in the past for debugging the site.
hakre 5y ago
a certificate is either valid or its not. this is more for administering it or for users that rely on it and want to know within build systems, at least that is where it did hit me. the failure then, the same. wondered although if there is some use in knowing an upcoming expiration. # curl + GNU date + GNU grep -P $ echo "cert days left: ~$(( ($(date +%s -d "$(curl -IvsS https://www.w3.org 2>&1 >/dev/null | grep -Po '(?<=^\* expire date: ).*')")-$(date +%s))/86400 ))" cert days left: ~396 but then what should the information give? that my build breaks, say next Tuesday? and what if until then the certificate expiration is enlarged?

indolering 5y ago

No, it was a mistake not to implement everything in DNS ... since that is what cryptographically determines ownership of a domain anyway. Any other certificate mechanism is just middle men selling snake oil and causing additional administrative overhead.

stjohnswarts 5y ago

I can't agree. It should be enforced with extreme prejudice. Some people's lives may depend on it.

SilverRed 5y ago
And their lives depend less when the site uses no certificate at all?

deleted 5y ago

[deleted]