Exim certificate revocation check (CRL) working!

Certificate revocation test within Exim - based on the patch the Vivek sent.

15879 SSL verify ok: depth=1 cert=/C=US/ST=Washington/L=Seattle/O=Credentia/OU=Certificate Services/

CN=Credentia Root Certification Authority 1

15879 About to call ssl_callback_SSLVerify_CRL

15879 CA CRL: Issuer: /C=US/ST=Washington/L=Seattle/O=Credentia/OU=Certificate 

Services/CN=Credentia Root Certification Authority 1, lastUpdate: Jan 26 16:18:13 2004 

GMT, nextUpdate: Jan 27 16:18:13 2004 GMT

15879 SSL peer: /C=US/ST=Washington/L=Seattle/O=Credentia/OU=Secure Mail 

Server/CN=giggler.foster.cc/emailAddress=root@foster.cc

15879 About to call ssl_callback_SSLVerify_CRL

15879 LOG: MAIN

15879   Certificate with serial 2 (0x2) revoked per CRL from issuer

/C=US/ST=Washington/L=Seattle/O=Credentia/OU=Certificate 

Services/CN=Credentia Root Certification Authority 1

15879 LOG: address_rewrite MAIN

15879   SSL CRL error: depth=0 error=certificate revoked 

cert=/C=US/ST=Washington/L=Seattle/O=Credentia/OU=Secure Mail 

Server/CN=giggler.foster.cc/emailAddress=root@foster.cc

15879 SSL info: SSLv3 read client certificate B

15879 SSL info: SSLv3 read client certificate B

15879 SSL info: SSLv3 read client certificate B

15879 LOG: MAIN

15879   TLS error on connection from giggler.foster.cc [216.254.62.183] (SSL_accept): 

error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

15879 TLS failed to start

15879 LOG: smtp_connection MAIN

patching exim for TLS certificate verification (expiration)

In order to investigate and patch exim to support proper certificate validation (expiration) I have setup everything on giggler.

The src is in /home/mdf/build/exim-4.30


Installs into /home/mdf/exim/


Run as '/home/mdf/exim/bin/exim -bd -d' and watch the debug output.


Make changes in exim-4.30/src/tls-openssl.c et al.


Rebuild and install using 'cd /home/mdf/build/exim-4.30/; make && make install'

The problem appears to be that X509_verify_cert(X509_STORE_CTX *ctx) is never called, but when I added that in... infinite loop.
Looking at the stunnel code (which exim's TLS support for openssl is based on) it appears that X509_verify_cert() is not call in it's verify_callback() routine, either (ssl.c). So I'm at a loss for now, I'll look at it again later.

48543 SSL info: SSLv3 write certificate request A
48543 SSL info: SSLv3 flush data
48543 LOG: MAIN
48543 Inside verify_callback, state is 0, dn=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=Certificate Authority/emailAddress=gshapiro@test.smtp.org
48543 LOG: MAIN
48543 SSL verify error: depth=1 error=self signed certificate in certificate chain cert=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=Certificate Authority/emailAddress=gshapiro@test.smtp.org
48543 SSL verify failure overridden (host in tls_try_verify_hosts)
48543 LOG: MAIN
48543 Inside verify_callback, state is 1, dn=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=Certificate Authority/emailAddress=gshapiro@test.smtp.org
48543 SSL verify ok: depth=1 cert=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=Certificate Authority/emailAddress=gshapiro@test.smtp.org
48543 LOG: MAIN
48543 Inside verify_callback, state is 0, dn=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=test.smtp.org/emailAddress=postmaster@test.smtp.org
48543 LOG: MAIN
48543 SSL verify error: depth=0 error=certificate has expired cert=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=test.smtp.org/emailAddress=postmaster@test.smtp.org
48543 SSL verify failure overridden (host in tls_try_verify_hosts)
48543 LOG: MAIN
48543 Inside verify_callback, state is 1, dn=/C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=test.smtp.org/emailAddress=postmaster@test.smtp.org
48543 SSL peer: /C=US/ST=California/L=Emeryville/O=test.smtp.org/CN=test.smtp.org/emailAddress=postmaster@test.smtp.org
48543 SSL info: SSLv3 read client certificate A
48543 SSL info: SSLv3 read client key exchange A


This verify_callback routine is scary. It's called twice, with two args and two other variables being evaluated inline, for a total of 2^5 possible states. I really just want to ask the following questions.

1. Is the certificate valid (not expired)
   
2. Is the certificate revoked (patchfile from Vivek)
   
3. Is the certificate signed by a known & trusted issuer (CA)
   

The other concern is that the verify_callback routine actually sets the certificate to be verified, even when it's not valid, so as to suppot the tls_try_verify functionality. This functionality should probably just exist outside of verify_callback, then the decision about when to continue or not based on the verification and validity of the peer certificate can be made independently, without being so intertwined.

Yahoo's Address Guard

Yahoo is offering an email service called Address Guard that touts disposable email addresses as a valid way to fight spam. It does NOT fight spam, it only hides your identity in a neurotic way. I did the same thing for years, using distinct email addresses for different online services and the like. It gets hard to keep track.

The downfall in the scheme is that there is really nothing to protect your primary identity... the one true identity... except careful dissemination.
If the primary email address is compromised the whole idea falls very flat. So at the heart of it, I think this is just another gimmick to make Yahoo money.

I'm actually not shooting down alternative addresses for different purposes. I have an address that I use exclusively for dealing with online companies and entities, and I just don't check it that often.

Lax delegation enforcement puts ccTLDs at risk

The lax enforcement of proper delegation, combined with the fact that a domain with all lame nameservers puts the burden on the parent nameservers, due to a lack of retransmission restraints on some resolvers.

This puts ccTLDs in an awkward position. To accept registrations from the general public means any joe can register a name under .to for instance, specify all lame nameservers, and unleash a worm or spam campaign. The resulting queries would likely consume all or most of the bandwidth available to the ccTLD nameservers, thus, that entire ccTLD namespace would sooner or later become unavailable due to denial-of-service (DOS).

Mail servers identified as using trusted certs

As of 2004-01-14 I have identified two MX servers using TLS certificates signed by public CAs. The first is issued by geotrust, the second by thawte.

2004-01-09 22:01:00 1AfCB7-0004nU-UN => xyz@speakeasy.org R=dnslookup T=remote_smtp

H=mx02.speakeasy.net [216.254.0.196] X=TLSv1:AES256-SHA:256

DN="/C=US

 /O=mail.speakeasy.net

 /OU=Business Registration: https://services.choicepoint.net/get.jsp?19582449

 /OU=See www.geotrust.com/quickssl/cps (c)03

 /OU=Domain Control Validated

 /CN=mail.speakeasy.net"



2004-01-10 07:35:40 1AfL9G-0005yg-3I <= owner-dnsop@lists.uoregon.edu

H=darkwing.uoregon.edu [128.223.142.13] U=root P=esmtp X=TLSv1:DES-CBC3-SHA:168

DN="/C=US

 /ST=Oregon

 /L=Eugene

 /O=University of Oregon

 /OU=Computing Center

 /CN=darkwing.uoregon.edu"

S=4414 id=y7vhdz3apam.wl@ocean.jinmei.org

Hi - just getting started