Earlier quoted context omitted.
Ultimately every cert is signed by a Certificate Authority. This is a "Trust Anchor". An authority that you trust implicitly. Your web browser maintains a list of these trusted parties, which are measured in the dozens and only change occasionally after careful scrutiny by Browser vendors. If your cert is not signed by one of these CAs, there is no way to verify it's veracity. That is why the browser gives a scary wa…
It would be interesting to see governments or domain registries set up ACME-compatible CAs. At the moment, it looks like there are options in Norway and Austria as well as the US: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...
What's the right UX for an expired certificate?
41–50 of 105 posts
Re: What's the right UX for an expired certificate?
#42Earlier quoted context omitted.
It would be interesting to see governments or domain registries set up ACME-compatible CAs. At the moment, it looks like there are options in Norway and Austria as well as the US: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...
Wouldn't this allow them to easily MITM you?
For example, the Netherlands government CA: https://cert.pkioverheid.nl/
Re: What's the right UX for an expired certificate?
#43Earlier quoted context omitted.
That analogy is a bit off because the certificate problem is on the supplier's side, not the customer's. A more apt analogy would be "no you can't see the doctor today, because their passport expired yesterday".
"The doctor is two minutes late, therefore all appointments today have been cancelled."
Re: What's the right UX for an expired certificate?
#44My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…
This is asking for trouble. If a site presents itself as https://foo, it should be foo according to global norms of what that means. No self-signed certificates.
What I think is needed is a way for a site to make a claim that it can prove in a decentralized way. Here are some examples of ways this could work:
https://serialnumber.vendor.com
The device has a certificate (with no expiration!) identifying it, signed by the vendor. The vendor provides a new kind of certificate saying that the device cert matches the serial number. The vendor refreshes this certificate periodically. There are thorny issues involving keeping this efficient, revoking problematic certificates, having the client (which likely has Internet access, but maybe not if the device is a router, for example) refresh the certificate if the device itself can’t, etc.
https://something_entirely_local
The origin could be literally a hash of the device private key. Sure, it’s not human readable, but it could be bookmarked. To make this work, routing info needs to be added too, giving, perhaps:
https://iot_device_(hash here)@address_or_domainname/
An IoT device could even have a QR code on it with a link:
https://iot_device_abcd1234@something_5678.local
Bonus points if there’s also a way to fetch pages like this over something like BLE for provisioning.
Re: What's the right UX for an expired certificate?
#45Earlier quoted context omitted.
> there should be a way to use TLS with a self-signed cert to say hey, I'm not making any strong claims of identity or privacy here, I just want some modicum of obfuscation of the traffic. How would a browser know whether a site presenting a self-signed cert is one where no strong claims of identity or privacy are needed or whether it's one where strong claims of identity are needed but which has been MitM'd. Also, d…
The browser shouldn't, the user is the one that needs to make that determination. But right now, the user doesn't even have that choice.
Problem is that technically *user should not make that determination* - for casual user TLS is transparent. Which takes burden of technically knowing if traffic was or was not MiTmed out of the question for end user. End users should make less technical decisions because they want to browse websites - not worry about if someone is injecting stuff in their traffic.
Re: What's the right UX for an expired certificate?
#46My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…
> there should be a way to use TLS with a self-signed cert to say hey, I'm not making any strong claims of identity or privacy here, I just want some modicum of obfuscation of the traffic. How would a browser know whether a site presenting a self-signed cert is one where no strong claims of identity or privacy are needed or whether it's one where strong claims of identity are needed but which has been MitM'd. Also, d…
Re: What's the right UX for an expired certificate?
#47My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…
> there should be a way to use TLS with a self-signed cert to say hey, I'm not making any strong claims of identity or privacy here, I just want some modicum of obfuscation of the traffic. How would a browser know whether a site presenting a self-signed cert is one where no strong claims of identity or privacy are needed or whether it's one where strong claims of identity are needed but which has been MitM'd. Also, d…
Re: What's the right UX for an expired certificate?
#48No completely and super hard disagree. An expired certificate is not a negotiable or "soft" error. What the hell is wrong with people today? It's not rocket science. Get your shit together or fuck off for the sake of everyone else. Nobody cares about all the layers of bureaucracy between you and renewing that cert. That's your fucking problem. Seriously no joke. Stop making this a "mere implementation detail" and you…
I really want you to show me how this is "not rocket science". Till then kindly "fuck off".
Re: What's the right UX for an expired certificate?
#49My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs…
> My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https:// . I think part of the issue was that priorities shifted. Initially, SSL was for commerce. You were looking for assurance that your credit card number wouldn't be captured in flight, and would go to the right, verified party. In this context, a s…
As I mentioned below, mitigations include: restricting this scheme to IP Addresses only, non-routable netblocks only, certain TLDs like .local, .lan .personal etc...
In regards to oppressive regimes, the state can also block all traffic unless you relent and install their CA cert in your browser bundle.
Mitigations here would be certificate transparency, pinning etc... I would also suggest that CA certs should be restricted to certain TLDs. Important websites can use all these mitigations, while still allowing my scheme for connecting to my Raspberry PI, kitten blog, or wifi router.
Re: What's the right UX for an expired certificate?
#50A user should not experience an expired certificate. Hence, the right UX is: null.