5 ms·

You don't, but I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption. Encryption pr

by dtech 6y ago

You don't, but I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption. Encryption prevents sniffing, Encryption + trust prevents sniffing and MITM. Providing sniffing protection is an upgrade. As an example, say HTTP would always upgrade to HTTPS with a server provided public key. That would be more secure than the HTTP we have today, even though it wouldn't prevent MITM.

skrebbel 6y ago
I don't understand, anyone who can MITM can also sniff, right?
- kop316 6y ago
  Yes they can. They simply decrypt, and reencrypt with their own self signed cert. If you have no way to verify the self-signed cert, you would never know.
- naniwaduni 6y ago
  An adversary with MitM capability needs to commit to being detectable in order to read encrypted traffic.
- dtech 6y ago
  but not everyone who can sniff can MITM, encryption always prevents sniffing
jackewiehose 6y ago
> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to. What kind of attack do you have in mind where someone can sniff on the data but not tamper with it? And how should a browser explain this situation to the user? No, the mindset that an unverified certificate is better than no encryption is very dangerous.
- trashfindhunter 6y ago
  > Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to. If a website previously using a self-signed certificate switches to plain HTTP - how will that help me verify the identity of the server the next time I visit? By removing the self-signed certificate, not only am I still unable to verify the identity of the server, but now my traffic is in plaintext for anyone on the local network to trivially intercept (in addition to whatever stranger I'm sending it to on the other end). I understand your sentiment, and I know the slippery slope that you are referring to when you say that it's a dangerous mindset to be okay with unverified certificates. Unencrypted communication however, is not a solution to that problem.
  - kerkeslager 6y ago
    > Unencrypted communication however, is not a solution to that problem. Could you point out who you are responding to who said that unencrypted communication is a solution to the problem? This strikes me as a straw man argument.
  - jackewiehose 6y ago
    > but now my traffic is in plaintext for anyone on the local network to trivially intercept If they are able to trivially intercept your network traffic they are probably also able to modify it (=> hijack untrusted HTTPS) or what scenario am I missing here? Of course unencrypted communication isn't a solution if your goal is to have secure communication. But so isn't untrusted communication. Either it's secure or not. You can't have something in-between. The browser would have to display an icon that says "This connection is secure but actually we don't really know so maybe it isn't". What are you supposed to make of such information?
    - tialaramex 6y ago
      So, a big concern which drove much of the adoption of HTTPS and other security technologies for the Internet is mass public surveillance, often justified as for "national security" purposes. The NSA for example is known to just suck up all the traffic it can get and put it in a pile for later analysis. Maybe your mention of "Make a bomb in chem class tomorrow" was just a joke to a close friend about how much you hate school, and maybe an analyst will realise that and move on when they see it, but civil liberties advocates think it'd be better if that analyst couldn't type "bomb" into an NSA search engine and see every mention of the word by anybody in your city in the last six weeks. I agree. Americans tried just telling the NSA not to collect this data, but the whole point of spooks is to do this stuff, short of terminating the agency they were always going to collect this data, it's in their nature. So the practical way forward is to encrypt everything. Any TLS connection can't be snooped. Only the participants get to see the data. The NSA isn't going to live MITM every single TLS connection so even with self-signed certificates the effect is you prevent mass surveillance. A targeted attack will MITM you, no doubt, and so that is the reason to insist on certificates, but it's wrong to insist as you do that there's no benefit without them.
kerkeslager 6y ago
> Encryption prevents sniffing, Encryption + trust prevents sniffing and MITM. Providing sniffing protection is an upgrade. In what real-world situation is that an upgrade?
- trashfindhunter 6y ago
  Ones that happen in the world you live in, homie.
  - kerkeslager 6y ago
    You claim that, yet you provide no examples.
tialaramex 6y ago
> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) The browsers agree with you. Blame Netscape (a corporation which no longer exists) in the mid-1990s (when people still thought Bill Clinton was cool and that the Web might be a fad) for this UI design mistake. Or maybe even Sir Tim himself since his "Web" has no security whatsoever. But, merely acknowledging that the present design is wrong doesn't fix it, and we can't rewrite history. So the shift has been gradual, but it's real. In this current Firefox for example an HTTPS site which presents a self-signed cert gets a warning interstitial, and then a cautionary UI marker but once I tell Firefox I trust this certificate it functions normally. On the other hand an HTTP site gets a red warning UI and some feature just don't work, and there is no way for the site to add those things, they're just outright prohibited with HTTP. If I try to fill out a form the browser reminds me it's insecure, and again there's no way to switch that off because it's true. Long term the goal is to deprecate HTTP entirely. You will have to use any remaining HTTP sites through a reverse proxy (or an old browser), perhaps somebody benevolent will operate a public proxy for those rare public sites that refused or are unable to upgrade to HTTPS. I'd guess we're maybe 5-10 years from that.
- dtech 6y ago
  > On the other hand an HTTP site gets a red warning UI and some feature just don't work, and there is no way for the site to add those things, they're just outright prohibited with HTTP. This is a very recent development. Until last year HTTP had no special behavior while self-signed HTTPS had a big "You WILL get hacked and all your creditcards stolen if you continue, do not continue unless you have a PhD in Computer Security" warning. Still has. Chrome shows a grey "not secure" on HTTP and a similar warning on self-signed. In terms of how secure HTTP vs self-signed is, the behavior should be reversed.

by dtech 6y ago

skrebbel 6y ago

I don't understand, anyone who can MITM can also sniff, right?

kop316 6y ago
Yes they can. They simply decrypt, and reencrypt with their own self signed cert. If you have no way to verify the self-signed cert, you would never know.
naniwaduni 6y ago
An adversary with MitM capability needs to commit to being detectable in order to read encrypted traffic.
dtech 6y ago
but not everyone who can sniff can MITM, encryption always prevents sniffing

jackewiehose 6y ago

> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to. What kind of attack do you have in mind where someone can sniff on the data but not tamper with it? And how should a browser explain this situation to the user? No, the mindset that an unverified certificate is better than no encryption is very dangerous.

trashfindhunter 6y ago
> Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to. If a website previously using a self-signed certificate switches to plain HTTP - how will that help me verify the identity of the server the next time I visit? By removing the self-signed certificate, not only am I still unable to verify the identity of the server, but now my traffic is in plaintext for anyone on the local network to trivially intercept (in addition to whatever stranger I'm sending it to on the other end). I understand your sentiment, and I know the slippery slope that you are referring to when you say that it's a dangerous mindset to be okay with unverified certificates. Unencrypted communication however, is not a solution to that problem.
- kerkeslager 6y ago
  > Unencrypted communication however, is not a solution to that problem. Could you point out who you are responding to who said that unencrypted communication is a solution to the problem? This strikes me as a straw man argument.
- jackewiehose 6y ago
  > but now my traffic is in plaintext for anyone on the local network to trivially intercept If they are able to trivially intercept your network traffic they are probably also able to modify it (=> hijack untrusted HTTPS) or what scenario am I missing here? Of course unencrypted communication isn't a solution if your goal is to have secure communication. But so isn't untrusted communication. Either it's secure or not. You can't have something in-between. The browser would have to display an icon that says "This connection is secure but actually we don't really know so maybe it isn't". What are you supposed to make of such information?
  - tialaramex 6y ago
    So, a big concern which drove much of the adoption of HTTPS and other security technologies for the Internet is mass public surveillance, often justified as for "national security" purposes. The NSA for example is known to just suck up all the traffic it can get and put it in a pile for later analysis. Maybe your mention of "Make a bomb in chem class tomorrow" was just a joke to a close friend about how much you hate school, and maybe an analyst will realise that and move on when they see it, but civil liberties advocates think it'd be better if that analyst couldn't type "bomb" into an NSA search engine and see every mention of the word by anybody in your city in the last six weeks. I agree. Americans tried just telling the NSA not to collect this data, but the whole point of spooks is to do this stuff, short of terminating the agency they were always going to collect this data, it's in their nature. So the practical way forward is to encrypt everything. Any TLS connection can't be snooped. Only the participants get to see the data. The NSA isn't going to live MITM every single TLS connection so even with self-signed certificates the effect is you prevent mass surveillance. A targeted attack will MITM you, no doubt, and so that is the reason to insist on certificates, but it's wrong to insist as you do that there's no benefit without them.

kerkeslager 6y ago

> Encryption prevents sniffing, Encryption + trust prevents sniffing and MITM. Providing sniffing protection is an upgrade. In what real-world situation is that an upgrade?

trashfindhunter 6y ago
Ones that happen in the world you live in, homie.
- kerkeslager 6y ago
  You claim that, yet you provide no examples.

tialaramex 6y ago

> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) The browsers agree with you. Blame Netscape (a corporation which no longer exists) in the mid-1990s (when people still thought Bill Clinton was cool and that the Web might be a fad) for this UI design mistake. Or maybe even Sir Tim himself since his "Web" has no security whatsoever. But, merely acknowledging that the present design is wrong doesn't fix it, and we can't rewrite history. So the shift has been gradual, but it's real. In this current Firefox for example an HTTPS site which presents a self-signed cert gets a warning interstitial, and then a cautionary UI marker but once I tell Firefox I trust this certificate it functions normally. On the other hand an HTTP site gets a red warning UI and some feature just don't work, and there is no way for the site to add those things, they're just outright prohibited with HTTP. If I try to fill out a form the browser reminds me it's insecure, and again there's no way to switch that off because it's true. Long term the goal is to deprecate HTTP entirely. You will have to use any remaining HTTP sites through a reverse proxy (or an old browser), perhaps somebody benevolent will operate a public proxy for those rare public sites that refused or are unable to upgrade to HTTPS. I'd guess we're maybe 5-10 years from that.

dtech 6y ago
> On the other hand an HTTP site gets a red warning UI and some feature just don't work, and there is no way for the site to add those things, they're just outright prohibited with HTTP. This is a very recent development. Until last year HTTP had no special behavior while self-signed HTTPS had a big "You WILL get hacked and all your creditcards stolen if you continue, do not continue unless you have a PhD in Computer Security" warning. Still has. Chrome shows a grey "not secure" on HTTP and a similar warning on self-signed. In terms of how secure HTTP vs self-signed is, the behavior should be reversed.