fetchmail-devel

[fetchmail-devel] Multiple sslfingerprint options and digests

[grarpamp <gra...@gm...>]

Hi all :)

Fetchmail needs the ability to specify multiple 'sslfingerprint'
options and digests per 'poll' stanza.

I noticed this when connecting to gmail. I think it's a load sharing
thing providers use. Google also has their own intermediate CA now
so more cert deployments could be expected.

At the moment, if you specify multiple sslfingerprint rc lines or
command line options, only the last one specified is checked. Any
prior sslfingerprint options are silently ignored. And the only
digest available is md5.

This is obviously frustrating users mail collection attempts :(


To reproduce the problem, run this and examine the certs and hashes.
The gmail certs happen to verify back to the root CA's. The
44a8...f1a9 cert occurs more frequently, the 9273...9f33 cert is
rarer. I've attached them both and the CA's involved.

If you are not seeing multiple certs, you may need to 'travel' and
debug with different source ip addresses... such as provided with
a worldwide proxy network like Tor.

i=10 ; while : ; do
 LD_PRELOAD=/tmp/tor/libtsocks.so.1 TSOCKS_CONF_FILE=/tmp/tor/tsocks.conf \
  openssl s_client -connect pop.gmail.com:pop3s < /dev/null > tcert$i 2>&1
 echo -n "$i: "
 openssl x509 -noout -fingerprint -md5 -in tcert$i
 i=`expr $i + 1`
done


Also related... from the BRANCH_6-3 NEWS file:

* --sslfingerprint may be removed from a future fetchmail version,
 because it's just too easily abused to create a false sense of
 security.

PLEASE don't remove this feature. I like it a lot and use it
everywhere possible, with --ssl and --sslcertck at the same time
as well, from trusted sources beforehand of course. Knowing when
the cert changes out from under you is very useful, even if only
for debugging or system verification. Especially if you connect
from untrusted locations or paths. Or you want to know about and
resolve them. It's also handy if the machine a user is connecting
from has a poor, untrusted or nonexistent collection of CA certs.
In that case, just the digest can be imported and used. Note that
openssl does not ship with a CA cert collection... admins usually
have to get it from mozilla... if they value PKI enough to think
of and bother with it.

There are blurbs in the man page that even talk about self-signed
certs being accepted with 'sslcertck'.


Overall, it would be good to see this feature enhanced to do both
md5 and sha1 to make cert collision attacks much more improbable
going forward... at least until the NIST 'SHA-3' hash competition
is done and that trickles down to the CA's and apps years from now.
Usage in the case of a single cert, where both must match, might
be like...

poll
 sslfingerprint-md5 <fp_md5>
 sslfingerprint-sha1 <fp_sha1>

In the case where multiple certs may be presented, group the hashes
as a set. Both hashes in the set must match. First check set cert1,
then set cert2, then set cert[n] until one set, or none, match the
presented cert...

poll
 sslfingerprint-cert1-md5 <fp_md5>
 sslfingerprint-cert1-sha1 <fp_sha1>
 sslfingerprint-cert2-md5 <fp_md5>
 sslfingerprint-cert2-sha1 <fp_sha1>
 sslfingerprint-cert[n]-md5 <fp_md5>
 sslfingerprint-cert[n]-sha1 <fp_sha1>

The '--' command line version of this should also do the right
thing.

Fetchmail should also print both the md5 and sha1 fingerprints from
the received certificate in the debug output.

Note that openssl supports mdc2, md2, md5, sha1. I understand that
some CA's also used, or may still use, the non-sha1 digests. Though
I guess sha1 is the only one used by sane CA's for new certs these
days. I don't know how many old ones are still in use on hosts. md5
and sha1 are enough until SHA-3.

And since the past always seems to apply to some future scenario
with new twists, this is surely not the last of the breed to be
proven out: http://www.win.tue.nl/hashclash/rogue-ca/

Extra checks are always good thing to have available.
Openssl probably has simple library routines to do this.

Thanks guys, and for fetchmail too, been using it for years :)


Hashes for people googling this:
MD5 Fingerprint=92:73:17:4C:34:4B:68:F7:B2:17:71:42:0D:7F:9F:33
SHA1 Fingerprint=30:36:A5:96:52:B6:64:18:12:E0:2C:98:82:1B:A4:C2:81:4F:BB:B5
34ceaf75
MD5 Fingerprint=44:A8:E9:2C:FB:A9:7E:6D:F9:DB:F3:62:B2:9E:F1:A9
SHA1 Fingerprint=51:21:45:CE:CE:99:19:87:7D:CE:3F:52:C0:31:0F:7E:FB:B4:6A:6F
7f549ca4
MD5 Fingerprint=67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
SHA1 Fingerprint=D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A
594f1775
MD5 Fingerprint=4E:5F:E4:78:5F:B5:68:37:DC:A1:C3:26:F9:F6:73:0B
SHA1 Fingerprint=F8:DF:AB:A0:BF:37:48:24:5B:4E:46:E7:6E:89:82:13:1F:ED:D7:46
d9b7a851

Re: [fetchmail-devel] [fetchmail-users] Multiple sslfingerprint options and digests

[grarpamp <gra...@gm...>]

Hi :) Folks in that ticket appear to be misunderstanding things
about the underlying crypto and why fingerprints are a necessary
safety check.

If one simply relies on checking the cert chain and blindly trusts
that model, as most of the world is conditioned to believe it is
sound, you are open to attack. Namely, of the sort in the posted
url, it is a good read, as are the referenced prior art. Both MD5
and SHA1 are theory broken and MD5 demonstrably so, as noted in the
literatre. So the hash part is of concern, at least in this case.

A CA takes a MD5 over certain fields in the cert and signs that MD5
digest, not the entire cert contents. CA's previously used MD5 and
failed to change their cert practices to SHA1 until a real world
break, oops. Anyways... So I don't have to swipe their private key.
All I have to do to forge a server cert is copy the signature from
any candidate real cert into my cert and manufacture the rest of
my cert contents so that they: a) work, b) make the fields have the
same digest as the real one. Which, as we all know by now is possible,
given time or new art, due to the whole hash collision thing.

However... if I copy a known good cert via trusted channels, and
take both the MD5 and SHA1 fingerprints of the DER form of that
cert, it's much closer to cryptographically impossible to manufacture
a cert that would match evarything. I could just as easily make
formal contact with the cert holder and get the prints that way or
receive them as part of a high security programme. Banks do this.

So there are two different fingerprints covering different areas.

Checking fingerprints over the entire DER cert will foil this attack
because it detects the contents that I manipulated to match the
field digest that was later signed. That is why openssl, browsers,
ssh, etc provide fingerprint calculating and verification functions...
totally separate from signature calc/verif capabilities.

So two types of checks should always be performed for maximum
security:

 A) cert chain trust = sig(hash(contents)) -> pki
  This is done with openssl verify -verbose
  aka: sslcertck
 B) DER fingerprint = hash(sig(hash(contents))
  This is done with openssl x509 -in <PEMcert> -noout -fingerprint -<sha1|md5>
   or
  openssl x509 -in <PEMcert> -outform DER | <sha1|md5>
  aka: sslfingerprint... with the enhancements in the prior note

Enhancing fetchmail to doubly check B with both MD5 and SHa1 shouldn't
be much extra coding or user effort. As an aside, it's fairly common
to find places using/publishing both hashes for various purposes.

Removing the check in B places all the beans on the hash function
in A, which is not good. Private keys are not even involved in this.
Defense in depth will save your butt :)

Give the user tools, let them decide how many they wish to deploy
and manage. I would adapt the docs to say that one should use both
A and B, or neither, with some short reasons why. And continue to
provide example openssl usage as is there now, to allow them to
accomplish it.

Note1: Not checking the fingerprints on self-signed certs... such
as are commonly found in internal corporate nets, edu's, org's, and
the many end user, developer, hacker and other low budget/tier
sites... is asking for trouble. Not publishing your prints, signed
by OpenPGP, is bad too.

Note2: The random serial fix just helps eliminate easier forms of
the hash collision attack, see the paper. It doesn't necessarily
prevent other forms or completely new math attacks, and definitely
doesn't prevent brute force.

Note3: The lists.berlios.de cert is expired, and MD5, though that
doesn't matter :) The Berlios_CA cert may be self-signed.

Hey, thanks for the pointer to the bug thing! I'll try to append
to the seemingly closed ticket. I'm out of time at the moment to
help out with correcting what is already in there, perhaps later.

And again for keeping up with all the maintenance to fetchmail :)

Re: [fetchmail-devel] BerliOS/mailing list companion web site X.509 certificates (was: Multiple sslfingerprint options and digests)

[Matthias A. <mat...@gm...>]

Am 11.08.2009, 23:44 Uhr, schrieb grarpamp <gra...@gm...>:

> Note3: The lists.berlios.de cert is expired, and MD5, though that
> doesn't matter :) The Berlios_CA cert may be self-signed.

Berlios's certificate management is a mystery to me (to spare other  
rants), and I can't seem to get a hold of an admin who could provide me  
with the CA's root certificate or to be bothered about expired or  
non-matching certficiates.

If anyone has a direct link to prod them to proper certificate management  
practices, that would be quite welcome...

-- 
Matthias Andree