Browse Prior Art Database

Renegotiation Capability of SSL/TLS Protocol Could be Strengthened

IP.com Disclosure Number: IPCOM000246783D
Publication Date: 2016-Jun-30
Document File: 3 page(s) / 38K

Publishing Venue

The IP.com Prior Art Database

Abstract

Described is a method that could strengthen the SSL/TLS renegotiation by using a unique route between the client and server when creating the session ID.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Renegotiation Capability of SSL /

/TLS Protocol Could be Strengthened

TLS Protocol Could be Strengthened

A "man in the middle" attack is still technically possible in the current implementation of SSL/TLS protocol. This is how it currently works:

FIRST HANDSHAKE:


The SSL Client sends a ClientHello message:
-----------------------------------
*** ClientHello, TLSv1
RandomCookie: GMT: 1349796376 bytes = { 169, 131, 46, 46, 73, 66, 59, 4, 110, 214, 25, 251, 242, 17, 249, 12, 105, 159, 55, 41, 161, 185, 55, 194, 244, 158, 89, 49 }

Session ID: {}

Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RENEGO_PROTECTION_REQUEST]
-----------------------------------
Then the SSL Server replies with the ServerHello message:
-----------------------------------
*** ServerHello, TLSv1
RandomCookie: GMT: 1349796376 bytes = { 124, 73, 67, 155, 110, 230, 55, 90, 164, 91, 165, 63, 80, 190, 92, 109, 241, 65, 207, 88, 51, 246, 202, 45, 1, 101, 200, 200 }

Session ID: {80, 116, 66, 24, 172, 150, 205, 97, 177, 129, 57, 27, 89, 72, 121, 253, 217, 138, 111, 234, 37, 179, 123, 186, 62, 134, 222, 161, 18, 70, 232, 36}

Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
-----------------------------------

    As you can see, the ServerHello message assigns a SessionID to the handshake; this handshake can be resumed in the future. If you have renegotiation enabled, you'll see something like the following message:

SECOND HANDSHAKE:
-----------------------------------
%% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 1860
*** ClientHello, TLSv1
RandomCookie: GMT: 1349796378 bytes = { 233, 164, 144, 163, 98, 61, 80, 96, 228, 178, 61, 55, 126, 134, 205, 1, 183, 148, 20, 105, 90, 171, 108, 140, 172, 183, 225, 208 }

Session ID: {80, 116, 66, 24, 172, 150, 205, 97, 177, 129, 57, 27, 89, 72, 121, 253, 217, 138, 111, 234, 37, 179, 123, 186, 62, 134, 222, 161, 18, 70, 232, 36}

Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RENEGO_PROTECTION_REQUEST]
-----------------------------------

    As you can see, the SSL client is using the same SessionID. This is derived from a RandomNumber generator. This leads to a very high vulnerability, which is called "man in the middle" attack, in case someone intercepts this SessionID. [*] Also, this leads to another vulnerability, which is a "Denial Of Service" attack, again, in case someone else intercepts this SessionID. As far as research showed, there are currently no known solutions.

The invention would be to augment the current protocol or even create a new

1


Page 02 of 3

protocol/mode to add an extra layer for uniqueness using "traceroute". The new enhancement can reinforce this capability by using the complete pat...