7 ms·

My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expi

My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https:// 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:// http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection. Especially for local LANs, but also for small websites, 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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. Also, the fact that the entire world's infrastructure relies on some small, centralised non-profit in the USA (LetsEncrypt) makes me very nervous. Ordinary citizens can end up on the wrong side of sanctions through no fault of their own...

andirk 4y ago
Good point! No encryption shows zero issue. Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?
- entropyie 4y ago
  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 warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons: 1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...). Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.
  - Tijdreiziger 4y ago
    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/ https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...
    - jonas-w 4y ago
      Wouldn't this allow them to easily MITM you?
      - Tijdreiziger 4y ago
        A lot of governments already have CAs, so they could MITM you anyway. For example, the Netherlands government CA: https://cert.pkioverheid.nl/ https://cert.pkioverheid.nl/
- tialaramex 4y ago
  The other answer to your question seemed to me to have guessed wrong what you're concerned about. My guess is that like a lot of non-experts, your thought was "Why do we need this CA role?" and that, fortunately, is something where I can appeal to your intuitions rather than needing some mathematical proof about cryptography you won't understand. This is about identity. How can we (and everybody else) agree on the identity of something? Is "Chris Pratt" the movie guy we've both heard of, or is it some Belgian guy's friend's brother you met once at a party? The Screen Actors Guild insists its members all have distinct names so you can tell them apart. If your real name is Clint Eastwood and you go into acting, too bad change it or you won't be allowed to work on most stuff with union rules. You don't need a legal change of name (although if you're a serious actor you might decide it's less bother to get one) but you must use a name distinct from those already in use in the industry. Naturally there can't be some objective "truth" to a name. People may say "She looks like a Deborah" but that's not really how it works - when we find someone in a coma with no ID we don't go "Oh, he looks like a Jim Smith, of 420 Springfield Crescent", we have to put out a public appeal with photos. If I show you a web page it may look like Wikipedia, but I can trivially do that myself, so the real Wikipedia is the one everybody agrees on, and if for some reason we all agreed tomorrow that's not Wikipedia, it wouldn't be. So, with no objective truth† we have to instead have an authority, and for everybody's convenience we should all trust at least roughly the same authorities, so we're all agreed about who we're talking about † We can use cryptography to "assign" things names, but these names aren't very satisfactory, that's how Tor's private services work, which is why they have ugly names like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion -- notice that all those letters are crucial, facebookwkhpilnemxj7asaniu7vnjjxiltxjqhye3mhbshg7kx5tfyd.onion is one letter different and would be a different Tor service not operated by Facebook.
  - peoplefromibiza 4y ago
    > How can we (and everybody else) agree on the identity of something? we do, I rephrase it, billions of people do it all the time everyday on WhatsApp. It's called TOFU The first T means Trust. Another example: Protonmail, it uses PGP, it works. The important thing for privacy is the encryption part, not the identity part. Even more so when we all know that full fledged HTTPS site put TENS OF MEGABYTES of garbage on their web pages to track people. Identity: I want it confirmed if I'm talking to my bank, but why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.
- drewmol 4y ago
  The CA signing provides different levels of validation. DV (Domain validation) certificates require demonstration of control over the dns record(s) to the CA, ensuring the (IP address) server responding to your request has demonstrated control of the domain name by which you addressed it, to the CA. Let’s say your local dns is poisoned to resolve to a nefarious server at a specific IP address for ss64.com, that server’s certificate won’t be signed by a CA (unless they also controlled ss64.com’s dns records, in which case there would have be no need to poison your local dns). Your connection to this server can still be encrypted via a certificate, but the CA won’t be providing validation of their identity or affiliation with the real ss64.com.
- ownagefool 4y ago
  TL;DR It's just for Identification. The signature on the public key matches what domain it should resolve, and said public key pairs with a private key that encrypts your data. Assuming you don't a) mishandle the private key, b) the Signatory has a reasonably process to assure that person with the private key should be able to encrypt the domain, and c) all potential trusted Signatories can be trusted, then you can reasonably assume the site you're visiting is legit. The actual encryption doesn't need identification. Doing so would ensure others can't listen to your conversation, but wouldn't help if the person you think you're talking to isn't actually the right person. This is a realistic problem, because there's nothing in DNS or routing that ensures trust.
SturgeonsLaw 4y ago
> there should be a way to use TLS with a self-signed cert Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.
- entropyie 4y ago
  Sure, what I had in mind was a more user-friendly UX. For example, if I could add something to the certificate subject to say: "This is an obfuscation only cert, not claiming identity or MITM resistance". Then, the browser would either show the address bar like a HTTP page, or maybe show a notification instead of a block page, saying: "This is the first time you have visited this page. Identity is not verified. Trust identity?" You can tell I don't do UX for a living ;-)
  - iso1631 4y ago
    For 90% of people there's two UI options 1) a button to let them get where they want to go 2) A button which doesn't let them get where they want to go
  - jeroenhd 4y ago
    > "This is the first time you have visited this page. Identity is not verified. Trust identity?" Users will click random buttons until the popup disappears. You can watch it happen in real time when you help the elderly with computer issues and don't say anything. Every option from cancel to close to OK is tried as whatever is happening doesn't work. Reading the error message itself is an action of last resort. There's a good reason you can only bypass certain TLS errors by typing "thisisunsafe" into the error screen in Chrome; people just clicked the ignore button until the problem disappeared and then ran into trouble.
ThePhysicist 4y ago
LetsEncrypt is not the only ACME provider, and there are hundreds of regular CAs. Nothing about TLS certificates is centralized, there's just market concentration as a result of good UI/UX by LetsEncrypt, but there are open-source ACME implementations available, the protocol itself is in the process of being standardized and nothing keeps other CAs from running the same service, and in fact many are planning to do just that.
- nisegami 4y ago
  >Nothing about TLS certificates is centralized You're right that there are additional ACME providiers, but the reliance on just a handful of default root cert stores is what makes HTTPS centralized, even if TLS isn't.
  - jeroenhd 4y ago
    Most big apps bundle their own certificates/certificate authorities for cert pinning already. They can switch to their own CA system any time. Sadly, DANE has failed because DNSSEC has failed on the American market. Hopefully we'll find an alternative for these protocols in the future.
vbezhenar 4y ago
I'm using strong protection in Chrome and it prevents me from browsing HTTP websites unless I explicitly allow it. So while you're correct, it's just a historic issue and soon browsers will treat HTTP like bad HTTPS but not in a sense you're proposing but rather forbid both.
pilif 4y ago
> 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, do this without the browser talking to some "mothership" to ask about what a domain should be treated us because that would leave that party in a position where it gets to all of your browsing history.
- nisegami 4y ago
  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.
  - ozim 4y ago
    You still can have untrustworthy page and user still has to make that determination with TLS or without. If you connect to bad guys server you still will get owned. 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.
- entropyie 4y ago
  DNS? crt.sh? Certificate Pinning? Apply this only to non-routable IPs? Apply this only to certain TLDs, such as: .local .lan .personal There are many options. Also, how would this be any worse than visiting a plain HTTP site instead?
  - pilif 4y ago
    DNS can be MitMd. crt.sh would be in a position to get all your browsing history. The local thing would work, but of course only for local hosts. It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.
dale_glass 4y ago
> My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https:// 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 self-signed certificate is somebody claiming "trust me, I'm a bank manager" despite being unable to prove any association with your bank. And somebody with an expired ID might be a former, disgruntled employee whose ID has expired because they don't work there anymore. Both of those are far more suspicious than somebody not claiming to be anything in particular. > Especially for local LANs, but also for small websites, 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. That's not really reliable. The moment you install that as a norm, you'll have various countries doing MITM and generating their own cert for the site. Any confidence such a scheme provides is extremely suspect, as it relies on nobody exploiting the flaw for personal benefit. > Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. That only works if you think your attack mode is a hacked/malicious access point at a cafe or hotel. If you're in a place like Russia or China the state has the resources to ensure you always get the same MITM-ed cert, unless you play games with VPNs, which may well land you on some sort of watch list.
- entropyie 4y ago
  As I said, I am well aware of the perils of MITM. There are mitigations for all your concerns, and in each case, the question should be: is this better or worse than plan HTTP. 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.
amluto 4y ago
> Especially for local LANs, but also for small websites, 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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. This is asking for trouble. If a site presents itself as https://foo 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 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 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 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 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.
lucideer 4y ago
> * My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https://.\\ https://.\\* I think that's a well-acknowledged issue but those who disagree on less-severe expiry warnings would simply argue here that it would be preferable to be strict in both cases and that the lax approach to http:// http:// is just legacy baggage we should work toward getting rid of. Personally, I'm a little on the fence. The expiry UX could definitely be "improved" (made more helpful) without making it more lax. Another thing to consider is that going from lax to strict is MUCH MUCH harder than going from strict to lax, so easing severity now would make it difficult to undo that change later.
- entropyie 4y ago
  That legacy baggage is the only thing that allows older hardware to connect to the modern network. It's the only thing that allows folks the agency and autonomy to setup their own services and share them with folks locally, without requiring the blessing and grace of a distant 3rd party authority. I've spent 20 years working with advanced PKI and cryptography in many different domains and form factors, and what I've learned is that even with the best of intentions, they are all fragile and their default state is broken, without constant maintenance. Availability and resilience to failure are key pillars to security that are often overlooked. In the past 20 years, all of the critical failures in PKI systems that I have seen were due to expiring certs, expiring CRLs, failure to distribute new PKI in time, accidental deletion of key PKI, missing intermediate certs. None were due to MITM, weak crypto, spoofed packets, use of plain HTTP. Make of that anecdote what you will.
  - jen20 4y ago
    > without requiring the blessing and grace of a distant 3rd party authority. Nothing stops you installing a private CA into the trusted roots for this kind of case.
    - entropyie 4y ago
      Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor. In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"? Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone peeking at all the surveillance traffic their Apps are sending to the internet.
bombcar 4y ago
Especially since all Let’s Encrypt cares about us a DNS proof-of-domain, it should be possible to negotiate that from the browser itself.
- jrochkind1 4y ago
  It is probably easier to give a browser a fake DNS result (ie, a MITM attack) than to do the same to the letencrypt authorizers. Fake DNS result/MITM is one of the things that the SSL cert is supposed to guard against. Possibly the only thing that a domain-validated cert has going for it over an anonymous cert. Allowing a domain cert to be "renegotiated" from the browser would seem to defeat the purpose of having a domain cert at all.
jrochkind1 4y ago
I seem to recall the browsers threatening to start issuing warnings for any http, but I guess it hasn't happened yet.

andirk 4y ago

Good point! No encryption shows zero issue. Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?

entropyie 4y ago
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 warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons: 1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...). Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.
- Tijdreiziger 4y ago
  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/ https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...
  - jonas-w 4y ago
    Wouldn't this allow them to easily MITM you?
    - Tijdreiziger 4y ago
      A lot of governments already have CAs, so they could MITM you anyway. For example, the Netherlands government CA: https://cert.pkioverheid.nl/ https://cert.pkioverheid.nl/
tialaramex 4y ago
The other answer to your question seemed to me to have guessed wrong what you're concerned about. My guess is that like a lot of non-experts, your thought was "Why do we need this CA role?" and that, fortunately, is something where I can appeal to your intuitions rather than needing some mathematical proof about cryptography you won't understand. This is about identity. How can we (and everybody else) agree on the identity of something? Is "Chris Pratt" the movie guy we've both heard of, or is it some Belgian guy's friend's brother you met once at a party? The Screen Actors Guild insists its members all have distinct names so you can tell them apart. If your real name is Clint Eastwood and you go into acting, too bad change it or you won't be allowed to work on most stuff with union rules. You don't need a legal change of name (although if you're a serious actor you might decide it's less bother to get one) but you must use a name distinct from those already in use in the industry. Naturally there can't be some objective "truth" to a name. People may say "She looks like a Deborah" but that's not really how it works - when we find someone in a coma with no ID we don't go "Oh, he looks like a Jim Smith, of 420 Springfield Crescent", we have to put out a public appeal with photos. If I show you a web page it may look like Wikipedia, but I can trivially do that myself, so the real Wikipedia is the one everybody agrees on, and if for some reason we all agreed tomorrow that's not Wikipedia, it wouldn't be. So, with no objective truth† we have to instead have an authority, and for everybody's convenience we should all trust at least roughly the same authorities, so we're all agreed about who we're talking about † We can use cryptography to "assign" things names, but these names aren't very satisfactory, that's how Tor's private services work, which is why they have ugly names like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion -- notice that all those letters are crucial, facebookwkhpilnemxj7asaniu7vnjjxiltxjqhye3mhbshg7kx5tfyd.onion is one letter different and would be a different Tor service not operated by Facebook.
- peoplefromibiza 4y ago
  > How can we (and everybody else) agree on the identity of something? we do, I rephrase it, billions of people do it all the time everyday on WhatsApp. It's called TOFU The first T means Trust. Another example: Protonmail, it uses PGP, it works. The important thing for privacy is the encryption part, not the identity part. Even more so when we all know that full fledged HTTPS site put TENS OF MEGABYTES of garbage on their web pages to track people. Identity: I want it confirmed if I'm talking to my bank, but why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.
drewmol 4y ago
The CA signing provides different levels of validation. DV (Domain validation) certificates require demonstration of control over the dns record(s) to the CA, ensuring the (IP address) server responding to your request has demonstrated control of the domain name by which you addressed it, to the CA. Let’s say your local dns is poisoned to resolve to a nefarious server at a specific IP address for ss64.com, that server’s certificate won’t be signed by a CA (unless they also controlled ss64.com’s dns records, in which case there would have be no need to poison your local dns). Your connection to this server can still be encrypted via a certificate, but the CA won’t be providing validation of their identity or affiliation with the real ss64.com.
ownagefool 4y ago
TL;DR It's just for Identification. The signature on the public key matches what domain it should resolve, and said public key pairs with a private key that encrypts your data. Assuming you don't a) mishandle the private key, b) the Signatory has a reasonably process to assure that person with the private key should be able to encrypt the domain, and c) all potential trusted Signatories can be trusted, then you can reasonably assume the site you're visiting is legit. The actual encryption doesn't need identification. Doing so would ensure others can't listen to your conversation, but wouldn't help if the person you think you're talking to isn't actually the right person. This is a realistic problem, because there's nothing in DNS or routing that ensures trust.

SturgeonsLaw 4y ago

> there should be a way to use TLS with a self-signed cert Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.

entropyie 4y ago
Sure, what I had in mind was a more user-friendly UX. For example, if I could add something to the certificate subject to say: "This is an obfuscation only cert, not claiming identity or MITM resistance". Then, the browser would either show the address bar like a HTTP page, or maybe show a notification instead of a block page, saying: "This is the first time you have visited this page. Identity is not verified. Trust identity?" You can tell I don't do UX for a living ;-)
- iso1631 4y ago
  For 90% of people there's two UI options 1) a button to let them get where they want to go 2) A button which doesn't let them get where they want to go
- jeroenhd 4y ago
  > "This is the first time you have visited this page. Identity is not verified. Trust identity?" Users will click random buttons until the popup disappears. You can watch it happen in real time when you help the elderly with computer issues and don't say anything. Every option from cancel to close to OK is tried as whatever is happening doesn't work. Reading the error message itself is an action of last resort. There's a good reason you can only bypass certain TLS errors by typing "thisisunsafe" into the error screen in Chrome; people just clicked the ignore button until the problem disappeared and then ran into trouble.

ThePhysicist 4y ago

LetsEncrypt is not the only ACME provider, and there are hundreds of regular CAs. Nothing about TLS certificates is centralized, there's just market concentration as a result of good UI/UX by LetsEncrypt, but there are open-source ACME implementations available, the protocol itself is in the process of being standardized and nothing keeps other CAs from running the same service, and in fact many are planning to do just that.

nisegami 4y ago
>Nothing about TLS certificates is centralized You're right that there are additional ACME providiers, but the reliance on just a handful of default root cert stores is what makes HTTPS centralized, even if TLS isn't.
- jeroenhd 4y ago
  Most big apps bundle their own certificates/certificate authorities for cert pinning already. They can switch to their own CA system any time. Sadly, DANE has failed because DNSSEC has failed on the American market. Hopefully we'll find an alternative for these protocols in the future.

vbezhenar 4y ago

I'm using strong protection in Chrome and it prevents me from browsing HTTP websites unless I explicitly allow it. So while you're correct, it's just a historic issue and soon browsers will treat HTTP like bad HTTPS but not in a sense you're proposing but rather forbid both.

pilif 4y ago

> 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, do this without the browser talking to some "mothership" to ask about what a domain should be treated us because that would leave that party in a position where it gets to all of your browsing history.

nisegami 4y ago
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.
- ozim 4y ago
  You still can have untrustworthy page and user still has to make that determination with TLS or without. If you connect to bad guys server you still will get owned. 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.
entropyie 4y ago
DNS? crt.sh? Certificate Pinning? Apply this only to non-routable IPs? Apply this only to certain TLDs, such as: .local .lan .personal There are many options. Also, how would this be any worse than visiting a plain HTTP site instead?
- pilif 4y ago
  DNS can be MitMd. crt.sh would be in a position to get all your browsing history. The local thing would work, but of course only for local hosts. It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.

dale_glass 4y ago

> My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https:// 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 self-signed certificate is somebody claiming "trust me, I'm a bank manager" despite being unable to prove any association with your bank. And somebody with an expired ID might be a former, disgruntled employee whose ID has expired because they don't work there anymore. Both of those are far more suspicious than somebody not claiming to be anything in particular. > Especially for local LANs, but also for small websites, 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. That's not really reliable. The moment you install that as a norm, you'll have various countries doing MITM and generating their own cert for the site. Any confidence such a scheme provides is extremely suspect, as it relies on nobody exploiting the flaw for personal benefit. > Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. That only works if you think your attack mode is a hacked/malicious access point at a cafe or hotel. If you're in a place like Russia or China the state has the resources to ensure you always get the same MITM-ed cert, unless you play games with VPNs, which may well land you on some sort of watch list.

entropyie 4y ago
As I said, I am well aware of the perils of MITM. There are mitigations for all your concerns, and in each case, the question should be: is this better or worse than plan HTTP. 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.

amluto 4y ago

> Especially for local LANs, but also for small websites, 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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed. This is asking for trouble. If a site presents itself as https://foo 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 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 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 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 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.

lucideer 4y ago

> * My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// http:// site than a self-signed or expired cert on https://.\\ https://.\\* I think that's a well-acknowledged issue but those who disagree on less-severe expiry warnings would simply argue here that it would be preferable to be strict in both cases and that the lax approach to http:// http:// is just legacy baggage we should work toward getting rid of. Personally, I'm a little on the fence. The expiry UX could definitely be "improved" (made more helpful) without making it more lax. Another thing to consider is that going from lax to strict is MUCH MUCH harder than going from strict to lax, so easing severity now would make it difficult to undo that change later.

entropyie 4y ago
That legacy baggage is the only thing that allows older hardware to connect to the modern network. It's the only thing that allows folks the agency and autonomy to setup their own services and share them with folks locally, without requiring the blessing and grace of a distant 3rd party authority. I've spent 20 years working with advanced PKI and cryptography in many different domains and form factors, and what I've learned is that even with the best of intentions, they are all fragile and their default state is broken, without constant maintenance. Availability and resilience to failure are key pillars to security that are often overlooked. In the past 20 years, all of the critical failures in PKI systems that I have seen were due to expiring certs, expiring CRLs, failure to distribute new PKI in time, accidental deletion of key PKI, missing intermediate certs. None were due to MITM, weak crypto, spoofed packets, use of plain HTTP. Make of that anecdote what you will.
- jen20 4y ago
  > without requiring the blessing and grace of a distant 3rd party authority. Nothing stops you installing a private CA into the trusted roots for this kind of case.
  - entropyie 4y ago
    Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor. In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"? Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone peeking at all the surveillance traffic their Apps are sending to the internet.

bombcar 4y ago

Especially since all Let’s Encrypt cares about us a DNS proof-of-domain, it should be possible to negotiate that from the browser itself.

jrochkind1 4y ago
It is probably easier to give a browser a fake DNS result (ie, a MITM attack) than to do the same to the letencrypt authorizers. Fake DNS result/MITM is one of the things that the SSL cert is supposed to guard against. Possibly the only thing that a domain-validated cert has going for it over an anonymous cert. Allowing a domain cert to be "renegotiated" from the browser would seem to defeat the purpose of having a domain cert at all.

jrochkind1 4y ago

I seem to recall the browsers threatening to start issuing warnings for any http, but I guess it hasn't happened yet.