Re: [Chicken-users] OpenSSL egg option defaults poll

[Thomas Chust]

On Tue, 28 Oct 2014, Florian Zumbiehl wrote:

> [...]
> I am not sure I understand what you mean--you never can protect against a
> client that doesn't want to protect the session, they always could just
> publish the session key, or the decrypted data, or whatever. The protection
> should always focus on third parties that try to undermine the security.
> [...]

Hello,

that's right, but you can also try to protect against a client that tries 
to obtain information from the server side to which it isn't entitled. 
However, selecting different cipher will help less there than selecting 
better versions of the protocol.

> [...]
> I don't see any serious security problems with the default. If the
> configuration of the peer isn't braindead, that will negotiate a reasonably
> secure cipher suite, the default connected to itself will negotiate
> ECDHE-RSA-AES256-GCM-SHA384 (if the necessary server-side initialization
> for ECDHE cipher suites has been done),
> [...]

Implementing the necessary server-side setup for the "normal" and 
elliptic-curve-based Diffie-Hellman schemes is high up on my priority list 
for the OpenSSL egg, too.

> [...]
> plus you could argue that RC4 is
> actually still more secure than CBC modes with TLS < 1.1 due to BEAST,
> unless both sides implement 1/n-1 splitting or the application protocol can
> not be used to perform the attack.
> [...]

Hmm, RC4 in its original form has a pretty large bias. Do you know if the 
SSL variant throws away the head of the random stream, which would reduce 
the predictability of the PRNG?

Anyway, CTR-based encryption modes with authentication like GCM, CCM, EAX 
and the like are probably fine if the underlying block cipher is strong.

> [...]
> I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
> roughly this should do the right thing (well, it's obviously taken from a
> server, but the principle should be applicable in the general case):
> [...]

Huh, interesting. The documentation of OpenSSL that I have installed 
doesn't mention those TLSv1_{1,2}_{server,client}_method functions 
anywhere, but they are declared in the header files. I must have 
overlooked them. Apparently, closely studying the headers files and trying 
to divine the meaning of the functions without documentation is still the 
way to go if you want to perform any useful operation with OpenSSL %-]

Somehow I'm tempted to start from scratch with a binding to GnuTLS or 
another library that has decent documentation ;-)

Ciao,
Thomas


--
When C++ is your hammer, every problem looks like your thumb.