Bug #1503 for EasyTCP: EasyTCP Encryption

Sun Sep 08 17:07:42 2002 BOBMATH [...] cpan.org - Ticket created

Subject:

EasyTCP Encryption

I took a look at EasyTCP, and noticed 4 serious security flaws in its encryption implementation. I'm not an expert on crypto, but I do know that each of these alone is deadly. 1) If Crypt::RSA is not used, symmetric encryption keys are sent across the network in the clear. Anyone who can see the data can also decrypt it, so encryption is worthless in this case. 2) An active attacker (one who can modify packets on the network) can undetectably prevent Crypt::RSA from being used. He simply needs to remove Crypt::RSA from the list of supported encryption modules. 3) A man-in-the-middle attacker can defeat the Crypt::RSA mode by replacing the RSA keys with his own. Here are a couple of tools that automate such an attack against other protocols: http://monkey.org/~dugsong/dsniff/ http://ettercap.sourceforge.net/ Why don't you use SSL? It has already fixed the problems listed above. 4) Perl's built-in (insecure) rand() function is used to generate cryptographic keys. An attacker could connect to the server, discover its internal random number generator state from the session key the server sends back, and use that information to guess the encryption key used with other clients. http://perlmonks.org/index.pl?node_id=151595

Sun Sep 08 23:27:59 2002 mina.cpan [...] naguib.ca - Correspondence added

Hello Bob Thanks for your email. I will address these issues one by one below. [BOBMATH - Sun Sep 8 17:07:42 2002]: Show quoted text

> 1) If Crypt::RSA is not used, symmetric encryption keys are sent > across the network in the clear. Anyone who can see the data can > also decrypt it, so encryption is worthless in this case.

This is a "chicken before the egg" logical loop. You can't transmit it encrypted unless you've negotiated an encryption scheme. This applies for data as well as the encryption scheme itself in case of symmetric encryption. I believe that any encryption is better than no-encryption at all. However, having that said, I do not consider any of the symmetric encryption options quite serious and it states so in the documents, that for serious security Crypt::RSA should be used. Show quoted text

> 2) An active attacker (one who can modify packets on the network) can > undetectably prevent Crypt::RSA from being used. He simply needs to > remove Crypt::RSA from the list of supported encryption modules.

That is correct. How do you propose they exchange the "encryption module availability" list while avoiding the above ? Show quoted text

> 3) A man-in-the-middle attacker can defeat the Crypt::RSA mode by > replacing the RSA keys with his own. Here are a couple of tools > that automate such an attack against other protocols: > http://monkey.org/~dugsong/dsniff/ > http://ettercap.sourceforge.net/ > > Why don't you use SSL? It has already fixed the problems listed above.

I will look into using the perl SSL module, however it will get quite tricky if one supports SSL and the other doesn't. I don't want the module to be hard especially for beginners, I'm also concerned about the "internal protocol" that EasyTCP offers, and how it could be tunneled through the SSL socket, or tunnel it through a normal socket if SSL was not available, and how to detect a listening server is running SSL or not etc... I'll give it some serious thought while your suggestions are also quite welcome. Alternatively, I can look into 1. How the SSL protocol circumvents the above problem or 2: Use signed packets to verify the integrity, however I will need to study all of the above first for holes. Show quoted text

> 4) Perl's built-in (insecure) rand() function is used to generate > cryptographic keys. An attacker could connect to the server, > discover its internal random number generator state from the > session key the server sends back, and use that information to > guess the encryption key used with other clients. > http://perlmonks.org/index.pl?node_id=151595

I will fix that by implementing Vipul's Crypt::Random::Provider::rand module for as-secure random numbers as possible (AFAIK) without requiring NET::EasyTCP to use external crypto providers and needing to be compiled. Again, thanks for your email. Let me know what you think of the points I've made. As with all software I write, I'm always open to suggestions and don't shy from change.

Tue Sep 10 12:40:01 2002 BOBMATH [...] cpan.org - Correspondence added

[MNAGUIB - Sun Sep 8 23:27:59 2002]: Show quoted text

> [Encryption keys in the clear] > This is a "chicken before the egg" logical loop. You can't transmit > it encrypted unless you've negotiated an encryption scheme.

Precisely. Either you arrange for the client and server to have a shared secret (password) beforehand, or you exchange it with public key techniques (typically RSA or DH). Show quoted text

> I believe that any encryption is better than no-encryption at all.

I suppose it could be a little better than nothing. It might keep your little brother from listening in on you with a standard packet sniffer when he's bored, even if it won't stop a determined attacker. On the other fork of the tongue, it's dangerous to give people a false sense of security. Show quoted text

> However, having that said, I do not consider any of the symmetric > encryption options quite serious and it states so in the documents, > that for serious security Crypt::RSA should be used.

That's fine, as long as the user of the module knows what he's getting. I just reread the module documentation, though, and I didn't see this warning anywhere. There is something in the changelog, but how many people read changelogs? I rarely do, unless I want to know if some specific bug has been fixed. The main pod documentation should contain an analysis of the actual security provided. Show quoted text

> [Removing Crypt::RSA from module list] > That is correct. How do you propose they exchange the "encryption > module availability" list while avoiding the above ?

SSL hashes all of the initialization messages into the session key. If an attacker modifies anything in transit, the key exchange fails. Show quoted text

> I will look into using the perl SSL module, however it will get quite > tricky if one supports SSL and the other doesn't. I don't want the > module to be hard especially for beginners ...

I have to admit that SSL is pretty complicated. Security is a complicated business, though. Even if you decide not to use SSL, I think it would be a good idea to learn how it solves the common problems. The SSH protocol is also pretty well designed (as far as I can tell), and it's a lot simpler. Show quoted text

> [Random numbers] > I will fix that by implementing Vipul's Crypt::Random::Provider::rand > module ...

Excellent. -bob mathews