Archive for February, 2009

Python SSL MitM Proxy

Posted by Tyler on February 17, 2009
Tools / No Comments

Just a quick post to share that pdp has released a Python SSL proxy. I haven’t had a chance to play with it yet but it definitely looks promising, so I figured I’d share it with everyone.

Tags: ,

SSLFail is SSL Enabled

Posted by Tyler on February 16, 2009
Site Related / 2 Comments

Update: A lot of people don’t like the idea of people issuing their own CA Certs… I saw some humour in a SSLFail CA cert that wasn’t shared. I also see no reason why SSL Certs should be as over priced as they are (that deserves it’s own blog post), so I won’t pay for one for a blog. So… Install the CA cert at your own risk.

So there have been some comments about SSLFail not having an SSL version. I’ve fixed this today and you can now access SSLFail via https://www.sslfail.com. The CA is SSLFail so by defaut you’ll get an error (in Firefox the message will read: ‘The certificate is not trusted because the issuer certificate is unknown.’ ). The SSLFail certificate is available for download, should you wish to install it.

Should anyone want a cert signed by SSLFail, I’m more than willing to do so… simply email — treguly (at) sslfail (dot) com.

Tags:

The Middler *FINALLY* Released

Posted by Tyler on February 09, 2009
Tools / No Comments

I really wish I’d be at ShmooCon for this, but getting news of it is more than enough.  I had first mentioned the Middler when I attended Jay’s talk at SecTor. Following the presentation I had a chance to sit down and further discuss the tool with Jay and I was really excited that the release was coming “later that day”. Later that day turned into months without any word of an announcement, but that’s over now… the tool is out and it’s very exciting.

Instead of continuing to discuss it myself (I plan a long blog post once I’ve had time to play with the Middler), I’m going to point you to a post on NovaInfosecPortal.com which contains further details. The Middler can be downloaded from the InGuardians website here.

Tags: , ,

SSLv3 Traces [Part 2]

Posted by jgraver on February 08, 2009
SSL Facts / No Comments

This SSL Packet Trace is based on the Server View found here. My goal is to add useful hash information to the packet dump which in its original form only contained the state register values.

These are the starting values for your MD5 and SHA-1 Hash Objects.
State = useless
Hash = digest() of all handshake data seen so far
Buf Hash = digest() of all 64 byte blocked handshake data
Buffered Data = 63 or less bytes of data waiting to be added to the hashes

Starting Values [0]
MD5 State:      67452301efcdab8998badcfe10325476
SHA State:      67452301efcdab8998badcfe10325476c3d2e1f0
MD5 Hash:       d41d8cd98f00b204e9800998ecf8427e
SHA Hash:       da39a3ee5e6b4b0d3255bfef95601890afd80709
Buf MD5 Hash:   d41d8cd98f00b204e9800998ecf8427e
Buf SHA Hash:   da39a3ee5e6b4b0d3255bfef95601890afd80709
Buffered Data [0]

Now each handshake section of the packet is added to the hash objects in 64 byte blocks. If you do not yet have 64 bytes to add you simply hold onto them in a buffer.

Client Hello [52]
MD5 State:      67452301efcdab8998badcfe10325476
SHA State:      67452301efcdab8998badcfe10325476c3d2e1f0
MD5 Hash:       56d14200dd0dc905d876474c98ac2e0e
SHA Hash:       677664bb8d411d0f757f593dfb2509194274177b
Buf MD5 Hash:   d41d8cd98f00b204e9800998ecf8427e
Buf SHA Hash:   da39a3ee5e6b4b0d3255bfef95601890afd80709
Buffered Data [52]
01 03 00 00 1b 00 00 00  10 01 00 80 03 00 80 06  ................
00 40 07 00 c0 00 00 04  00 00 0a 00 00 09 00 00  .@..............
03 00 00 06 d8 90 d7 86  4e 5c 92 9f 90 07 da 83  ........N\......
1c 25 89 01                                       .%..

While the hash states listed in the original packet traces were useless the buffered data was pretty handy, it was a clear indication of what pieces to add to the hash objects. In this packet we add 74 more bytes to the 52 we had saved up from before. After using up the first 64 bytes we are left with 62 left over.

Server Hello [74]
MD5 state:      88c9b8dfc144c3163d5f0a6f5c8050c2
SHA state:      626c5d48a75e632814b572a7a634256195d4b038
MD5 Hash:       613d367016bd9df00fa25e8761c0af57
SHA Hash:       bbf09b7676a261bb679cd618919450e14a62aec7
Buf MD5 Hash:   5e612aa87f6994fb836aba168af7eb10
Buf SHA Hash:   34d1303dde2ff4f0bfede8a22e8307fcb7a297bf
Buffered Data [62]
ce e0 92 9c ff 03 be d3  c5 25 a2 ec 61 85 b1 ea  .........%..a...
93 bf a0 5e a9 79 1c 8a  ed 16 20 00 00 4f 47 95  ...^.y.... ..OG.
8f 49 f8 7b d8 41 71 5f  36 f9 6f 7d a2 31 fa 25  .I.{.Aq_6.o}.1.%
07 8e 45 3c 0e d9 e7 d4  d2 86 5c 00 04 00        ..E<......\...

This is where the packets start getting really long. Although the certificates are long (and very complicated) they are one of the very few SSL packets with ASCII printable text. When looking at a packet dump these are the most recognizable packets of an SSL transaction.

Server Certificate [1331]
MD5 state:      9cbff56d42b7e94ef4ff1acf323703fa
SHA state:      bb19323f4e8e5ab8b1cbe0a2687c706bd8f29c00
MD5 Hash:       1c0168d2bf58b931d3900e043b3d0811
SHA Hash:       192cd1976ae06f563062c05744ab632aebd54226
Buf MD5 Hash:   658a2e15ea5d2bd02b3b8c19b91bb8ff
Buf SHA Hash:   ee8d3d2e7c232414b45c2d94045abfbe4d78f2f9
Buffered Data [49]
a7 62 b3 5b 8e 4d 82 bd  4d 85 eb 0d 5a 87 c0 41  .b.[.M..M...Z..A
c9 a6 c2 69 9c ee 81 49  2a fb 01 55 6f b1 df 21  ...i...I*..Uo..!
a7 b0 70 e4 5d 34 3b 90  29 f9 14 c3 2e 07 79 13  ..p.]4;.).....y.
c7                                                .

The following packet is where this demo trace really goes off the rails. Netscape chose to illustrate one of the more complicated capabilities of SSL. Although client side certificates are essential to SSL VPN connections, they are very seldom seen in standard HTTPS sessions.

Server Certificate Request [4846]
MD5 state:      8e428cd82e39d5b55907f503aba04860
SHA1 state:     c6a44cb5395684f2bd4f6340a9e71646f27f44a1
MD5 Hash:       944f3c49e385599172d9c418a93c4bf0
SHA Hash:       274b63fb35c478f7358e9f2b5334cb17c96728c5
Buf MD5 Hash:   54c0082e941319cb5aea8683d83f745a
Buf SHA Hash:   54b3a5bd49a6d2b8c2265d4166bf5feb2b17a1f4
Buffered Data [31]
 1e 30 1c 06 03 55 04 03  14 15 47 65 74 20 53 6d  .0...U....Get Sm
 61 72 74 63 61 72 64 20  44 65 6d 6f 20 43 41     artcard Demo CA

Finally we get to the Server Hello Done message.

Server Hello Done [4]
MD5 state:      8e428cd82e39d5b55907f503aba04860
SHA state:      c6a44cb5395684f2bd4f6340a9e71646f27f44a1
MD5 Hash:       d100fddd68dc017674a40f3cc28921d4
SHA Hash:       4bd7ccd3e58633b629e2bb2f51cc90aa0973d9b4
Buf MD5 Hash:   54c0082e941319cb5aea8683d83f745a
Buf SHA Hash:   54b3a5bd49a6d2b8c2265d4166bf5feb2b17a1f4
Buffered Data [35]
 1e 30 1c 06 03 55 04 03  14 15 47 65 74 20 53 6d  .0...U....Get Sm
 61 72 74 63 61 72 64 20  44 65 6d 6f 20 43 41 0e  artcard Demo CA.
 00 00 00                                          ...

Client sends its identity to the Server. This step is not commonly seen.

Client Certificate [1330]
MD5 state:      87508b0c13815c09c8c3d6e1c21acdea
SHA state:      5cfaa109407fc96ac3ca17120fdb98899772153a
MD5 Hash:       b508728fb32560bcd8d4dce42cea601e
SHA Hash:       b6dbc745718ed93d8ad2237b2e2aea8d73cfd3a5
Buf MD5 Hash:   b7bb5762de2898dd0b995e91f9c30e85
Buf SHA Hash:   eba03e1be44f281b97b0b709316a916353be3da8
Buffered Data [21]
 6f b1 df 21 a7 b0 70 e4  5d 34 3b 90 29 f9 14 c3  o..!..p.]4;.)...
 2e 07 79 13 c7                                    ..y..

Now here is the first packet with actual encryption. This packet contains the pre-master secret that has been asymmetrically encrypted with the server’s public key. This pre-master secret will be used to calculate the symmetric key. I will focus on this packet in a future post as it is very interesting.

Client Key Exchange [68]
MD5 state:      250fb55d512afd7f4854468080c702a9
SHA state:      cf323bf6a3ca8feb6b10e4f5101104276472968d
MD5 Hash:       54eb606b1f4352c10c52d240091602b7
SHA Hash:       65141df5f72d09f62828f95ed8de803e0a009716
Buf MD5 Hash:   b699de2ef33abd107ede96e69faf64a7
Buf SHA Hash:   b91d39ce7f125cf8f7b1996607478c4f618a6616
Buffered Data [25]
 88 a4 60 56 61 57 c9 4f  5e 3a 1f f2 86 12 16 38  ..`VaW.O^:.....8
 36 1c 3d c6 b8 0a 3f bd  88                       6.=...?..

Certificate Verify message – not commonly seen as client authentication is rare.

Certificate Verify [70]
MD5 state:      0cde7c7c27e9771142037f53633d4736
SHA state:      f6b217ec76f0d9ddda324813462ca026fe925ba3
MD5 Hash:       f92d49e65ac3d9a74de397f064db1adf
SHA Hash:       69c1b5559a70c2c489b57b4b9ba0e4c93c7b667c
Buf MD5 Hash:   b6ec7929879ba9b378fe4081442940d9
Buf SHA Hash:   45848df7885b538bd7c0df282a8701fb1ccfaf6f
Buffered Data [31]
 77 28 96 8e b5 61 74 f2  84 1c 31 a2 3f 4f 58 78  w(...at...1.?OXx
 11 88 72 4e ed 70 e8 ac  e9 82 37 ec 8d 32 7b     ..rN.p....7..2{

The Client Change Cipher Spec message is not included in the hashes. The Client Finished message however is. This packet (or portion of a packet) is the first symmetrically encrypted data we have seen so far. At this point in the handshake both the server and client posses a shared key.

Client Finished [40]
MD5 state:      f6b0a72e2150598caa3fb2fe89f69207
SHA state:      56341040456e541453cd46246e6ddff8789c7ee0
MD5 Hash:       cb815a237cf657b82b5bdb8e686d8a7b
SHA Hash:       732a54c36c4346d076727a8ff7856361adfaeec7
Buf MD5 Hash:   33329f6bde606b5ffd7516031f3ff610
Buf SHA Hash:   3e9fe0f55988bdb950d710e74d3279866b77713a
Buffered Data [7]
 ba c1 0f d4 a3 0f 67                              ......g

When this packet is unencrypted you will find a message that can only be verified if you have all the handshake data seen thus far. This is a little harder than just adding a couple of captured packets, as several portions of the message need to be excluded (all record data and change cipher spec messages). The server then does the same thing with this newly included data and completes the handshake by constructing the server finished message. I will look at this final step in my next post.

Tags:

Potentially 219K Expired SSL Certs?

Posted by Tyler on February 06, 2009
SSLFail / 2 Comments

Royal Pingdom has a post up mention that Netcraft has announced there are now one million sites that are using SSL. That’s valid certs, trusted by a third party, not expired and where the common name matches the hostname.  That’s a far cry from the 3293 found in Netcrafts first SSL survey.

Does this survey catch everything? Probably not, but it’s most likely a good starting point.

Now, how did Royal Pingdom determine that there are potentially 219K in expired certs? They based it on a 2007 survey from Venafi (referenced here), that said 18% of Fortune 1000 websites had expired certificates. They applied the percentage to the Netcraft total and, voila… 219K. They also go on to say that even if you have that it’s still 100K websites with expired certificates.

I’d be willing to wager a guess that if the number is off it’s mark, that it’s probably too low rather than two high. I encounter sites all the time with expired certs. Mind you, since we started SSLFail.com, I’ve had a harder time finding them.  However, I did happen to stumble across one just the other day and since we don’t feature screenshots with IE often enough… here you go.

OpenRCE.org Expired SSL

OpenRCE.org Expired SSL

Tags: , ,