STARTTLS and certificates Re: [ANNOUNCE] OfflineIMAP v6.3.4-rc3 released

[Sebastian Spaeth]

On Fri, 8 Jul 2011 14:58:03 +0200, Johannes Stezenbach <js at sig21.net> wrote:
> > > Which makes it completely useless.  
> > 
> > That's a bit harsh. It prevents eavesdroppers from getting your
> > passwords and your mail contents if they are able to wiretap a connection. It
> > won't prevent man-in-the-middle attacks, that is true. And it is why I
> > still prefer a "real" ssl connection to my server.
> 
> Well, IMHO the point of using encryption is to protect
> me from eavesdroppers.  If it doesn't, then it is useless to me.
> It's as simple as that.

Good for us then, because it *does* protect us from eavesdropping, as in
listening in (http://en.wikipedia.org/wiki/Eavesdropping). It does *not*
protect against active attacks, such as man-in-the-middle. I never
claimed otherwise.

For MIM-protection I really want to implement SSL fingerprint checking,
(to not be dependent on CA certs) but that requires some architectural
changes. And you might have noticed that we are pushing through changes
as quick as we can. If you look at both the number of committers and
commits at http://www.ohloh.net/p/offlineimap/analyses/latest you'll see
that offlineimap has never been more active than now. Granted, these
metrics don't say a lot about project quality, but it shows that things
are proceeding.

> If you remember CVE-2010-4532, other people seem to have
> the same expectation.

I remember the issue, and I had sent patches to disable SSLv2, but no I
don't remember that we had been assigned a CVE because no one ever
pointed me to it.

> > The thing, is that this is something that probably best belongs into
> > imaplib2 itself, which sets up the ssl socket. Otherwise we have to
> > override/extend/modify quite some functions in imaplib2 to trick it into
> > verifying connections.
> 
> Yes, I think imaplib2 should allow to pass the necessary parameters.
> It's probably easy to add.

I'm happy that you'll be working with them to integrate it. ;P Did you
know that every time when someone "It's probably easy to add" one
open source developer dies?

Seriously, sure it should be done. And so should ssl fingerprinting and
a whole lot of other stuff. But I feel we have achieved more in the last
6 months than the whole project did over the last 6 years. I have to
admit that I feel a bit offended if you deride the efforts the I and
others have put in as "useless". Call it selfish and petty, but that's how
we humans are. 

I look forward to the many eyeballs to contribute better solutions. You
clearly know more about TLS/SSL than I do, and you have shown that you
understand python. I am grateful for the advice and input that you have
given on security-related issues. But if you say "useless", I'll say
'show me the code' to do it any better.

> > What we probably could and should do is to document the lack of CA Cert
> > verification in the starttls case in offlineimap.conf. 
> 
> That's better than giving users a false sense of security.

I'd say, not documenting it is an omission (bug) on our side. We don't want to
pretend security when there is none. IMHO, automatically encrypting
traffic is still better than sending it over the wire in clear, even if
we haven't reached perfect security yet.
 
> > P.S. I still don't get why python/openssl don't strictly disable the
> > SSLv2 by default, and why there is no convenient method to disable SSLv2
> > before python 3.2. I did sent some patches some months back that achieved
> > this though.
> 
> Every webbrowser allows you to configure which SSL/TLS version to use/allow.

Yes, unfortunately not python and python's ssl module before python 3.2.

> I think that would be appropriate for offlineimap, too.
> "Explicit is better than implicit" is what they say in PEP 20.

I don't think they mean that everything should be configurable by
that. What I'm saying is that long-known insecure encryptions shouldn't
be hard to turn off, and they currently are. We can work around it and
should do so. But it's still working around.

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110708/293d3a91/attachment-0001.sig>