User: Password:
|
|
Subscribe / Log in / New account

New URI suggestion

New URI suggestion

Posted Sep 16, 2011 17:22 UTC (Fri) by borthner (guest, #4277)
In reply to: Certificates and "authorities" by Simetrical
Parent article: Certificates and "authorities"

May I suggest that httpe:// would be an appropriate scheme for encrypted but not authenticated traffic? This would solve a number of use cases. I get very tired of clicking allow on self-signed certificates for internal sites, but I'm too lazy (and overworked) to set up my own CA and import the CA into every browser on every computer I use. Browsers could take it as a given that httpe:// traffic would be allowed for any certificate, since the principal purpose would be to ensure encryption, rather than to ensure authentication. Sites where authentication of the server is critical would continue to use the https:// URI scheme.


(Log in to post comments)

New URI suggestion

Posted Sep 16, 2011 17:28 UTC (Fri) by jrn (subscriber, #64214) [Link]

Encryption without _some_ sort of authentication is useless. For example, after a DNS cache poisoning attack, the other end could be a spy who is forwarding your data to the actual intended recipient. If you are lucky enough to have a DNS setup that is immune to cache poisoning, then that's a form of authentication.

New URI suggestion

Posted Sep 16, 2011 22:14 UTC (Fri) by Simetrical (guest, #53439) [Link]

It's not actually useless. For one thing, it's possible to design a protocol where any MITM attack can be detected after the fact. tcpcrypt creates session ids in the course of setting up the encryption, with the property that they will match if and only if there was no MITM. Thus clients could conceivably store the session keys and compare them later over an authenticated channel.

The clients could also compare the session id's in some ad hoc way at the application layer. This will detect a MITM if the attacker is just blindly intercepting the encryption without understanding the higher-level protocol. For instance, if web browsers supported something like tcpcrypt, the current client session id could be exposed to JavaScript. Then obfuscated site-specific JavaScript code (complicated enough that it can't be automatically detected) could compare the client and server session id's, and bail out if they mismatch. A targeted attack against the particular site could work around this, but something that just intercepts all HTTPE traffic blindly would be detected.

Additionally, you could design the encryption protocol so that the initial stages are indistinguishable from an encryption-with-authentication protocol. Using tcpcrypt again as an example, you can layer auth on top of it by just setting up encryption as usual and then sending the server's session id to the client, signed with the server's certified public key. Then the attacker has to decide whether to try a MITM attack before knowing whether it has any chance of working. If he tries it and it turns out there is auth, he's detected, guaranteed.

So it's not true that encryption without authentication is useless. It does nothing against an ideal attacker, so it gives no guarantees. But it can make it a lot easier to detect attackers who are careless, and can make it harder for even careful attackers to pull off indiscriminate attacks with no risk of detection.

But I'm not sure it would be any easier to get such an encryption scheme working in browsers than to fix HTTPS so every site can use it. If we had SNI support and DNSSEC stapling support in all browsers of consequence, and DNSSEC were readily available for all domains, then good tools could conceivably make HTTPS about as easy to set up and maintain as a hypothetical HTTPE.

New URI suggestion

Posted Oct 18, 2011 20:59 UTC (Tue) by rich0 (guest, #55509) [Link]

Agreed, and by forcing an active attack it makes detection and countermeasures possible.

Police could trace cookie theft to some coffee shop, then set up shop in the shop. They'd browse to some site and wait for somebody to MITM their connection (they'd be running software that detects an IP for gmail/facebook/etc that isn't valid). Then they'd capture MAC IDs, camera images, and maybe even use DF to figure out who the culprit is. They'd have probable cause to make an arrest and search a laptop to confirm it was used. Then you nail them to the wall and publicize this. Pretty soon the level of casual hacking goes WAY down.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds