5 ms·

The NSA can see what pages you read, and men in the middle can modify the page to insert malicious JS or ads or whatever without HTTPS.

kickscondor 6y ago
Ok - next question then: why do browsers block self-signed certs? If Lets Encrypt now allows any domain to get a cert, what's the harm in a self-signed cert? Seems like a step up from plain HTTP.
- ocdtrekkie 6y ago
  The theory here is a self-signed cert could be from anyone (including the NSA) and you wouldn't know. Unless you explicitly trusted the certificate you were using, like enterprises do.
  - neop1x 6y ago
    NSA can probably already issue certs from some of the widely-trusted roots. If someone as big as NSA wanted to MITM you, you wouldn't notice...
- closeparen 6y ago
  What you are trusting, when you trust a CA, is that it will only issue a certificate for a domain to someone it has verified as the owner. A self-signed cert could be from a man in the middle attacker. An active MITM is a relatively more exotic threat than a passive observer. In the days when certificates cost money, there was a legitimate argument that you shouldn't need the whole elaborate active-MITM defense just to get protection against passive snooping. But now that you can get both for free... just use Let's Encrypt.
  - DivineEntropy 6y ago
    Small nit, verification is only meant to prove control over the domain, not ownership.
- deleted 6y ago
  [deleted]
- laughinghan 6y ago
  The man-in-the-middle can self-sign their own certs and present it to you as the site's own self-signed cert. Unless you have some way to verify self-signed certs out-of-band, they're useless.
  - josephg 6y ago
    They’re not useless. They stop passive adversaries, like the Australian government. They just don’t stop active adversaries. Browser security warnings imply https > http > self signed https. The correct order of should be https > self signed https > http.
    - laughinghan 6y ago
      Interesting point. BTW I love your blog and your work on ShareJS :)
    - throwaway525142 6y ago
      We're getting there, HTTP is going to be marked as insecure in the future as well. It's just the massive amount of HTTP sites that couldn't get marked as insecure before, due to the then resulting warning fatigue in users.
    - zhenyavinogrdov 6y ago
      Allowing untrusted certificates for https, and showing just a warning for them, would make it impossible for websites to ensure that their traffic is not intercepted
- CGamesPlay 6y ago
  I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self-signed certificates much less common, I doubt there's going to be energy put into improving the experience with them.
  - tialaramex 6y ago
    As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case. If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist. The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.
  - momentoftop 6y ago
    An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.
Lammy 6y ago
The NSA can still see that just via the metadata of me making the connections necessary to load the encrypted page contents.
- tialaramex 6y ago
  If they are focused on you then they can probably do that although it may take considerable work, such as spidering an entire web site to correlate resources on the site against timing and size information. Without encryption we know the NSA takes the approach of just bulk collecting everything they can to filter after the fact. So rather than an assigned agent trying to discern what Public Enemy #1 Lammy is up to right now, and painstakingly concluding you have probably just read a Wikipedia article about Jaffa cakes, if you don't have encryption what happens is that the automation notes "Lammy looked at http://en.wikipedia.org/wiki/Jaffa_Cakes http://en.wikipedia.org/wiki/Jaffa_Cakes" as you click and it goes into the vast heap of stuff snooped that second even though you aren't under any suspicion and it's probably irrelevant. This bulk surveillance is an unjustified attack on everybody's privacy.
traceddd 6y ago
To be fair, they probably can anyways, since the site willingly handed over their keys to Cloudflare, or rely on some Google CDN, host on EC2, etc. It’s the second or third tier nation state actors that you can really make a difference with.
gsich 6y ago
As a site owner that is somehow not my problem. It's not my fault that you have a shitty ISP. I can understand and support that argument. I do TLS only for my stuff however.
- inquirerofsorts 6y ago
  > It's not my fault that you have a shitty ISP. Really don't think you're grasping this and lack an understanding of packet routing. Please type: traceroute apache.org It's not just your ISP that's potentially shitty, it's every single hop on that list. Even worse if the person is using an open wifi connection. Apache will happily serve you an insecure connection, they are the 80th top site on the internet. This type of stuff should be called out by technologists and it's incredibly disappointing when its handwaved away.
  - gsich 6y ago
    That is still not my problem as a site owner.

kickscondor 6y ago

Ok - next question then: why do browsers block self-signed certs? If Lets Encrypt now allows any domain to get a cert, what's the harm in a self-signed cert? Seems like a step up from plain HTTP.

ocdtrekkie 6y ago
The theory here is a self-signed cert could be from anyone (including the NSA) and you wouldn't know. Unless you explicitly trusted the certificate you were using, like enterprises do.
- neop1x 6y ago
  NSA can probably already issue certs from some of the widely-trusted roots. If someone as big as NSA wanted to MITM you, you wouldn't notice...
closeparen 6y ago
What you are trusting, when you trust a CA, is that it will only issue a certificate for a domain to someone it has verified as the owner. A self-signed cert could be from a man in the middle attacker. An active MITM is a relatively more exotic threat than a passive observer. In the days when certificates cost money, there was a legitimate argument that you shouldn't need the whole elaborate active-MITM defense just to get protection against passive snooping. But now that you can get both for free... just use Let's Encrypt.
- DivineEntropy 6y ago
  Small nit, verification is only meant to prove control over the domain, not ownership.
deleted 6y ago
[deleted]
laughinghan 6y ago
The man-in-the-middle can self-sign their own certs and present it to you as the site's own self-signed cert. Unless you have some way to verify self-signed certs out-of-band, they're useless.
- josephg 6y ago
  They’re not useless. They stop passive adversaries, like the Australian government. They just don’t stop active adversaries. Browser security warnings imply https > http > self signed https. The correct order of should be https > self signed https > http.
  - laughinghan 6y ago
    Interesting point. BTW I love your blog and your work on ShareJS :)
  - throwaway525142 6y ago
    We're getting there, HTTP is going to be marked as insecure in the future as well. It's just the massive amount of HTTP sites that couldn't get marked as insecure before, due to the then resulting warning fatigue in users.
  - zhenyavinogrdov 6y ago
    Allowing untrusted certificates for https, and showing just a warning for them, would make it impossible for websites to ensure that their traffic is not intercepted
CGamesPlay 6y ago
I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self-signed certificates much less common, I doubt there's going to be energy put into improving the experience with them.
- tialaramex 6y ago
  As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case. If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist. The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.
- momentoftop 6y ago
  An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.

Lammy 6y ago

The NSA can still see that just via the metadata of me making the connections necessary to load the encrypted page contents.

tialaramex 6y ago
If they are focused on you then they can probably do that although it may take considerable work, such as spidering an entire web site to correlate resources on the site against timing and size information. Without encryption we know the NSA takes the approach of just bulk collecting everything they can to filter after the fact. So rather than an assigned agent trying to discern what Public Enemy #1 Lammy is up to right now, and painstakingly concluding you have probably just read a Wikipedia article about Jaffa cakes, if you don't have encryption what happens is that the automation notes "Lammy looked at http://en.wikipedia.org/wiki/Jaffa_Cakes http://en.wikipedia.org/wiki/Jaffa_Cakes" as you click and it goes into the vast heap of stuff snooped that second even though you aren't under any suspicion and it's probably irrelevant. This bulk surveillance is an unjustified attack on everybody's privacy.

traceddd 6y ago

To be fair, they probably can anyways, since the site willingly handed over their keys to Cloudflare, or rely on some Google CDN, host on EC2, etc. It’s the second or third tier nation state actors that you can really make a difference with.

gsich 6y ago

As a site owner that is somehow not my problem. It's not my fault that you have a shitty ISP. I can understand and support that argument. I do TLS only for my stuff however.

inquirerofsorts 6y ago
> It's not my fault that you have a shitty ISP. Really don't think you're grasping this and lack an understanding of packet routing. Please type: traceroute apache.org It's not just your ISP that's potentially shitty, it's every single hop on that list. Even worse if the person is using an open wifi connection. Apache will happily serve you an insecure connection, they are the 80th top site on the internet. This type of stuff should be called out by technologists and it's incredibly disappointing when its handwaved away.
- gsich 6y ago
  That is still not my problem as a site owner.