3 ms·

Everyone always defends this, and I can't understand why. Here's the way I see it: unsecure-cert= me + some unknown entity can read it. no-cert = me + anyone

Everyone always defends this, and I can't understand why. Here's the way I see it: unsecure-cert= me + some unknown entity can read it. no-cert = me + anyone can read it. I'd rather have some shady unknown entity read it, than everyone read it. Of course, a warning for both should exist, but IMO, the 2nd is much worse. Am I mis-understanding how this works?

agwa 11y ago
An encrypted-but-unauthenticated connection is not readable just by some unknown entity, but by an arbitrary, unbounded number of unknown entities, which is practically the same as "anyone." Anyone who's in a position to passively eavesdrop an unencrypted connection is usually able to actively eavesdrop an encrypted-but-unauthenticated connection with just a bit more work.
- CaptSpify 11y ago
  OK, so then lets change my equation: unsecure-cert= me + some unknown entity + possibly others no-cert = me + some unknown entity + absolutely others So, and insecure-cert still seems like the lesser evil?
  - agwa 11y ago
    An unencrypted connection isn't "absolutely" seen by others. If no one eavesdrops on it, it's private, just as an encrypted-but-unauthenticated connection is private if no one actively attacks it. Theoretically, an untrusted cert is the lesser evil since active attacks should be harder/more expensive than passive attacks, but no one knows exactly how much harder/more expensive they are in practice. This makes me very hesitant to declare one better than the other. Ultimately, browsers are going to start warning about unencrypted connections, and hopefully one day browsers will treat them just as severely as connections with untrusted certs. Unfortunately, we have to undo decades of bad practices first, which is a slow process.
tomjen3 11y ago
Lets take the common case of public wifi with no encryption. I can trivially listen to all the connections and get what information is being sent - how do I intercept the traffic?
- agwa 11y ago
  Use ARP spoofing to masquerade as the router, use DHCP spoofing to deliver a rogue default gateway or DNS server, or set up your own access point that uses the same SSID.

agwa 11y ago

An encrypted-but-unauthenticated connection is not readable just by some unknown entity, but by an arbitrary, unbounded number of unknown entities, which is practically the same as "anyone." Anyone who's in a position to passively eavesdrop an unencrypted connection is usually able to actively eavesdrop an encrypted-but-unauthenticated connection with just a bit more work.

CaptSpify 11y ago
OK, so then lets change my equation: unsecure-cert= me + some unknown entity + possibly others no-cert = me + some unknown entity + absolutely others So, and insecure-cert still seems like the lesser evil?
- agwa 11y ago
  An unencrypted connection isn't "absolutely" seen by others. If no one eavesdrops on it, it's private, just as an encrypted-but-unauthenticated connection is private if no one actively attacks it. Theoretically, an untrusted cert is the lesser evil since active attacks should be harder/more expensive than passive attacks, but no one knows exactly how much harder/more expensive they are in practice. This makes me very hesitant to declare one better than the other. Ultimately, browsers are going to start warning about unencrypted connections, and hopefully one day browsers will treat them just as severely as connections with untrusted certs. Unfortunately, we have to undo decades of bad practices first, which is a slow process.

tomjen3 11y ago

Lets take the common case of public wifi with no encryption. I can trivially listen to all the connections and get what information is being sent - how do I intercept the traffic?

agwa 11y ago
Use ARP spoofing to masquerade as the router, use DHCP spoofing to deliver a rogue default gateway or DNS server, or set up your own access point that uses the same SSID.