chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Florian Zumbiehl
Subject: Re: [Chicken-users] OpenSSL egg option defaults poll
Date: Wed, 29 Oct 2014 22:25:57 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

> 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

So, you'd actually be protecting the association between the server and the
legitimate client against an unauthorized third party, no?

> entitled. However, selecting different cipher will help less there
> than selecting better versions of the protocol.

Neither will help, as the client will be able to decrypt the data anyhow?
Though I have the feeling we might be talking past each other ... =:-)

> 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?

I'm pretty sure it does, so the bias is only strong, not large ... or
something ;-)

Don't get me wrong, I'm not saying RC4 is a good cipher, my point is:
neither is CBC with predictable IVs ;-)

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

Well, yes ... except that making high-performance AES constant-time in
software is difficult (impossible?), which means that on platforms without
AES-NI or similar, you get timing leaks, which is particularly bad if
that's reachable without authentication (because it is part of the
authentication). And you need TLS 1.2 for AEAD modes anyway, while explicit
IVs for CBC were introduced with 1.1, so BEAST isn't a problem there
anyhow. The padding oracle due to MAC-then-encrypt still might be, of
course ...

> >[...]
> >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 %-]

I tend to use the online version on openssl.org ... doesn't know about
TLSv1_2_method either, even though TLS 1.2 is mentioned, but at least about
1_1! ;-)

But yeah, I don't think you can get anywhere without grepping in headers
and reading existing code that uses OpenSSL ...

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

Well, from what you hear about the code quality of GnuTLS, I'm not that
sure ... ;-)

Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]