Dumping SMTP over TLS traffic

This is the analysis of TLS traffic over SMTP by way of ssldump.  The server requested client cert and the client cert (gmail) was verified ok.  However, I could not identify which part dealt with SSL client certificate verification.

# ssldump -i eth0 port 25
New TCP connection #1: mail-ie0-f170.google.com(37742) <-> transfer(25)
1 1  1.4201 (1.4201)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
        TLS_ECDHE_RSA_WITH_RC4_128_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  1.4221 (0.0020)  S>C  Handshake
      ServerHello
        Version 3.3
        session_id[0]=

        cipherSuite         TLS_RSA_WITH_AES_128_GCM_SHA256
        compressionMethod                   NULL
1 3  1.4221 (0.0000)  S>C  Handshake
      Certificate
Error: short handshake length: expected 17172 got 16380
Error: short handshake length: expected 4608083 got 792
1 4  1.6004 (0.1782)  S>C  Handshake
1 5  1.6004 (0.0000)  S>C  Handshake
1 6  1.7820 (0.1816)  C>S  Handshake
      Certificate
1 7  1.7820 (0.0000)  C>S  Handshake
      ClientKeyExchange
1 8  1.7820 (0.0000)  C>S  Handshake
      CertificateVerify
Not enough data. Found 258 bytes (expecting 16384)
1 9  1.7820 (0.0000)  C>S  ChangeCipherSpec
1 10 1.7820 (0.0000)  C>S  Handshake
1 11 1.7916 (0.0096)  S>C  Handshake
1 12 1.7916 (0.0000)  S>C  ChangeCipherSpec
1 13 1.7916 (0.0000)  S>C  Handshake
1 14 1.9699 (0.1782)  C>S  application_data
1 15 1.9703 (0.0004)  S>C  application_data
1 16 2.1483 (0.1779)  C>S  application_data
1 17 2.1484 (0.0000)  C>S  application_data
1 18 2.1484 (0.0000)  C>S  application_data
1 19 2.1779 (0.0294)  S>C  application_data
1 20 2.3952 (0.2173)  S>C  application_data
1 21 2.3952 (0.0000)  S>C  application_data
1 22 2.5747 (0.1794)  C>S  application_data
1 23 2.5747 (0.0000)  C>S  application_data
1 24 2.7329 (0.1582)  S>C  application_data
1 25 2.9110 (0.1780)  C>S  application_data
1    2.9111 (0.0000)  C>S  TCP FIN
1 26 2.9113 (0.0001)  S>C  application_data
1 27 2.9115 (0.0002)  S>C  Alert
1    2.9115 (0.0000)  S>C  TCP FIN

New OFCA mobile speedtest app

This is the results of new OFCA speedtest app in testing 802.11ac WiFi speeds.  Surprise !!!

Opendkim SignTable and KeyTable

As a member of PISA and ISOC HK, I occasionally need to use the email address warren@isoc.hk and warren.kwok@pisa.org.hk from my web-based email client to send outgoing emails.  However, as the DKIM signature is binded to a single sender domain only, the outgoing emails bearing the above two mentioned sender addresses can not have DKIM signature.  Fortunately, opendkim provides a SignTable which specifies which email addresses outside the default domain can be issued with signature.  Interestingly, if the SMTP server is providing email hosting to multiple domains, all email addresses of the domains can be signed.   This also reminds me of the file KeyTable which of course by its name means different domains can use different keys and selectors.    If I have time, I will try all these out to strengthen my understanding on DKIM.

DKIM crashed

My DKIM signature on outgoing emails has crashed over 3 months.  As a good security practice, I changed the key some time ago and uploaded the public key as a DNS text record.  In the course of checking the key before updating the DNS, a space character was inadvertently inserted which I still could not figure out how such thing could have happened.  By now the root cause is known and rectified, every outgoing has reinstated the DKIM signature for the receiving SMTP server to verify.   What a bad luck.   

Some years ago, I stumbled through an IT magazine saying that PGP, S/MIME and DKIM are the protocols for securing emails.  While they are use public key cryptographic approach, DKIM can not encrypt the email body.  It can only authenticate the sender.  The other obvious advantage is that it can help the sender to gain higher scores in the sender reputation and the likelihood of treating emails from the sender as spam or malicious emails is much reduced.   Last but not least, the DKIM verification can also ensure that message body is not tampered by man-in-the-middle attack in the course of delivery. 

上賊車

如果你現在三十嵗出頭，供樓按及二按用去收入的七成，還要供三十年。被困在這樣的供樓壓力下，你沒餘錢再進修，更何況生兒育女和供養父母，你的人生除了為磚頭賣命外，還有甚麼意義?

在此要奉勸那些80後， 不要拿走老豆老母嘅大半生積蓄或棺材本做首期， 佢哋無欠你架。 要上賊車就要靠自己， 輸贏都喺你自己，老豆老母吾喺你嘅賭本，兩老萬一遇上大病， 佢哋仲點會有錢入院做手術呀。

PuTTY

PuTTY, addicted to it forever !