In Which I Try to Learn SSL

‹prev | My Chain | next›

I had planned on moving back into SPDY proper, but I cannot let my difficulties with SSL pass without giving it one more try. Yesterday, I was unable to sniff SSL packets (even with the private key) of a SPDY session. I really do not understand where I am having difficulty, which is not a place that I like to be.

So tonight, I would like to try to it again with an Apache server. Following along with the Ubuntu guide, I

sudo apt-get install apache2
sudo a2enmod ssl
sudo a2ensite default-ssl

# Edit /etc/apache2/sites-enabled/default-ssl
        SSLCertificateFile    /etc/ssl/certs/cert.pem
        SSLCertificateKeyFile /etc/ssl/private/key.pem

With that, I again try to sniff SSL packets with ssldump:

ssldump -n -a -A -dX -H -k key.pem -i eth1
...
2 3  0.0626 (0.0000)  S>CV3.1(563)  Handshake
      Certificate
2 4  0.0626 (0.0000)  S>CV3.1(397)  Handshake
      ServerKeyExchange
2 5  0.0626 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
2 6  0.0662 (0.0036)  C>SV3.1(134)  Handshake
      ClientKeyExchange
2 7  0.0662 (0.0000)  C>SV3.1(1)  ChangeCipherSpec
2 8  0.0662 (0.0000)  C>SV3.1(48)  Handshake
2 9  0.0662 (0.0000)  C>SV3.1(368)  application_data
2 10 0.1155 (0.0492)  S>CV3.1(218)  Handshake
      dss_fixed_dh2 11 0.1155 (0.0000)  S>CV3.1(1)  ChangeCipherSpec
2 12 0.1155 (0.0000)  S>CV3.1(48)  Handshake
2 13 0.1291 (0.0136)  S>CV3.1(272)  application_data
2 14 0.1291 (0.0000)  S>CV3.1(48)  application_data
2 15 0.1291 (0.0000)  S>CV3.1(160)  application_data
2 16 0.1291 (0.0000)  S>CV3.1(48)  application_data
2 17 0.2809 (0.1518)  C>SV3.1(64)  application_data
2 18 0.2850 (0.0041)  S>CV3.1(96)  application_data
2 19 0.2850 (0.0000)  S>CV3.1(32)  application_data
2 20 0.2850 (0.0000)  S>CV3.1(256)  application_data
2 21 0.2850 (0.0000)  S>CV3.1(48)  application_data

Ah ha! So I am just and SSL idiot, not an ssldump idiot. I am still not seeing the actual application data even with Apache.

Per the ssldump troubleshooting guide, the two most common reasons for not seeing application data are (1) not supplying a private key and (2) supplying the wrong one. I am definitely supplying a key. I am also certain that I am supplying the right one. I inspect the certificate in the browser:



That looks to be the same as the one I generated last night. For good measure, I initiate a root session and run ssldump directly in /etc/ssl/private with no change in the results.

With the first two causes of non-decryption checked off, I am left with the third and final, "using one of the ephemeral keying modes". Eh?

I am unsure how I could be using such a beast, but the troubleshooting guide goes on to say that a "sure sign of this case is when the server is sending the ServerKeyExchange message. Indeed, the server is sending a ServerKeyExchange message. So how do I get a static key? Fortunately, that question has already been asked and answered, I need an engine in the list:

chris@chris-VirtualBox:/etc/apache2$ openssl ciphers -v kRSA
AES256-SHA256           SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5 
AES128-SHA256           SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5 
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5 
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=MD5 
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
NULL-SHA256             SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA256
NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5 

(except, I believe, the EXP / export ones)

Unfortunately, I still get no joy regardless of the options I send into genrsa:

openssl genrsa -out key.pem -des
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 30 -in request.pem -signkey key.pem -out cert.pem

I did have this working the other day, but I am forced to come to the conclusion that the difference was the client (using the --with-spdy=ssl Chrome option).

I think I can live with this. If I really need to packet sniff SSL, I can use that option, otherwise I will stick with Chrome's built-in SPDY log.


Day #10