Re: Saving Opportunistic Encryption
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area.
Worth discussing at least.
No, anything requiring publishing DNS records won't fly. OE is *opportunistic*. It doesn't care about what the true identity of the opposite party is. Any shmuck on dynamic IP should be able to use it instantly, with no observable performance degradation, using a simple patch. If it doesn't fit these minimal requirements, it will die, just the same way FreeS/WAN did. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]
Eugen Leitl wrote:
No, anything requiring publishing DNS records won't fly. OE is *opportunistic*. It doesn't care about what the true identity of the opposite party is. Any shmuck on dynamic IP should be able to use it instantly, with no observable performance degradation, using a simple patch.
If it doesn't fit these minimal requirements, it will die, just the same way FreeS/WAN did.
I absolutely agree. While it's possible to do things like MIM attacks if you don't know who the other guy is, look at how successful SSH is over any other kind of solution. Its biggest competitor at the time it was introduced was kerberized telnet/ftp. How many networks do you know that use Kerberos instead of ssh these days? Look at how many folks use PGP - those who really know it and want it, or those who know enough about it and have some easily automated implementation that plugs in to their mail client. (i.e. commercial pgp with Eudora/Outlook plug in. As an aside, I'm still pissed off that the Mozilla mail client doesn't support PGP/GPG in addition to S/MIME or whatever the hell..) Adding another infrastructure requirement that requires ISP layer changes will exponentially raise resistance to its adoption. While I do run my own server for mail/web, 99.9% of the internet luser population doesn't - and even so, I chose not to run my own DNS server. (Allowing register.com to do so makes it safer for me: it's one less service that might be compromised due to possible bugs.) Making it optional to add that infrastructure layer - whether it's via DNS, LDAP, signed public keys, web o' trust / pgp keyserver, finger, or even something entirely new, is probably the safer way to go, BUT don't require it. There do exist transparent web caching proxies out there (usually advertised as web accelerators.) I ran across such a few months ago when our satellite office couldn't connect to one of our servers. We were using private dns virtual host names to access management web pages on our servers. However the proxy intercepted those requests, and tried to resolve DNS, but obviously couldn't, so everyone in the office got a DNS error. It took some pretty strong words to get the ISP to even admit that they were using such a beast, much less disable it just for us. It's certainly possible to create a proxy to do MitM interception that would foil even SSH. This wouldn't work so well against mobile devices which might fortuitously use a different route, but would work very well one hop above the server if that's the only pipe the server has. There are ways to protect against this such as publishing a line for the known-hosts entry by other means, but no one does this (yet?) (i.e: sneakernet, finger, web page, pgp signed/encrypted email, over the telephone, etc.) (Another useful thing is to use public keys for SSH instead of passwords: this way the attacker won't be able to reuse your password - but you're still compromised the second you login.) There are some rare cases where you absolutely want to know who you are talking to. For example an https server that allows control of financial data. Even in that case the server doesn't fully know who the client is, and doesn't need to (in order to establish the secure link) -- until a login (or CC info) is presented. In the case of using OE to talk to a server, the client already has some idea of the server's identity, and the server will eventually have some idea of who the client is. As an aside: Just doing the above to encapsulate emails won't help at all against spamming: the spammers will just randomly generate throw away public keys, etc. They've already written trojan spammers with their own SMTP servers built in, it's only a few more (thousand?) lines of code to incrementally bypass that layer as well. I've already seen a few years ago spam sites that return "yahoo.com" and "msn.com" in reverse DNS, but doing traceroutes reveals that they're actually in Korea or China, etc. So you can't fully rely on (spoofable) DNS info anyway. If any of you remember the recent virii attacks where the attachment is a password protected zip file with the password in the body of the email, guess what: the evil ones kicked it up a notch once more. Just yesterday, I saw a new form of this on cpunx: instead of a ZIP attachment, the new malware uses a RAR archive, and instead of the password being in clear text, it's inside an a randomly named attached .GIF file! They've not obscured it, so it's possible to add OCR to the anti-virus code, but it's now it's that much harder for the anti-virus to block. Just as the virus authors evolve their code to adapt their offenses to the defenses of virus scanners, so will the spammers evolve their code to bypass spam filters, and we've already seen that spammers use virii/worms to spread their code... Distributed computing is already here. Shame that it's biggest use is currently for evil. Ugh! :(
a couple nitpicks on otherwise interesting points... On Wed, Mar 17, 2004 at 09:02:17AM -0500, sunder wrote:
Look at how many folks use PGP - those who really know it and want it, or those who know enough about it and have some easily automated implementation that plugs in to their mail client. (i.e. commercial pgp with Eudora/Outlook plug in. As an aside, I'm still pissed off that the Mozilla mail client doesn't support PGP/GPG in addition to S/MIME or whatever the hell..)
There's a well-supported extension for that: http://enigmail.mozdev.org/ Actually, plans are in the works to make S/MIME an extension as well, so the two will soon be on equal footing.
There are ways to protect against this such as publishing a line for the known-hosts entry by other means, but no one does this (yet?) (i.e: sneakernet, finger, web page, pgp signed/encrypted email, over the telephone, etc.) (Another useful thing is to use public keys for SSH instead of passwords: this way the attacker won't be able to reuse your password - but you're still compromised the second you login.)
Out-of-band transmission of known-hosts entries has been standard operating procedure everywhere *I* have used ssh for the past 10 years. I thought everyone did that. regards, petard
On Wed, 17 Mar 2004, Eugen Leitl wrote:
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area.
Worth discussing at least.
No, anything requiring publishing DNS records won't fly. OE is *opportunistic*. It doesn't care about what the true identity of the opposite party is. Any shmuck on dynamic IP should be able to use it instantly, with no observable performance degradation, using a simple patch.
If it doesn't fit these minimal requirements, it will die, just the same way FreeS/WAN did.
I discussed it with friends. There could be a way to advertise the OE availability, at least for TCP connections; my original idea was to use some magic number in the payload (which is normally zero) in the TCP/SYN and TCP/SYNACK packets. I was advised against this, as these packets are likely to be thrown away, and got suggested that there are various TCP options in the header. Maybe we could hijack one of them, eg. use the MD5 checksum option otherwise used by BGP (RFC 2385) to advertise our support for OE. The field is 128 bits of data we can use for a magic number and a bitfield of options. It is defined in RFCs, so it should be valid. We could put it into TCP/SYN packets when opening a connection, to advertise we support OE; the server then can use the same mechanism to send back confirmation of its OE support, and the method (if present) that can be used for authenticating its identity. The disadvantage is that we still have some risk that some routers will throw such packets away; see the problems eg. ECN has. However, some RFC offers a remedy for this, as it defines that if the first TCP/SYN with ECN support set doesn't get a SYNACK, the retry is WITHOUT the ECN offer. (This principle introduces the possibility of failure to use OE if the SYN packet with the OE (or the corresponding ACK) offer gets dropped due to congestion, but it should introduce no additional overheads (except the need to retry TCP/SYN in case it gets dropped due to non-RFC-compliant infrastructure on the link). Another disadvantage is that we don't protect UDP, due to lack of the header options. The advantage could be the possibility to implement this transparently on eg. the firmware of a NAT box; it has to track the connection states anyway, so it should be capable of mangling the first TCP/SYN packet by putting the OE offer in, and then strip it from the answers before passing it back, and handle the encryption in transparent manner. This way we got big savings in terms of effort needed to deploy OE between a heterogenous LAN and the Net; just upgrade the router. This scheme, as all OE are, is susceptible to an attack by stripping the OE offers from the packets. It, however, is not the passive way anymore, is more expensive, poses more difficulties, and a variant of eg. "arpwatch" userspace daemon can alert us that something like that is happening, that sites that used to use OE don't do so anymore, or that their identities are suspiciously changed. Told something like this to the crew of OpenSWAN developers. Got some reaction, but it's too soon to know more. Opinions, comments?
participants (4)
-
Eugen Leitl -
petard -
sunder -
Thomas Shaddack