Més d’un mes després de que es fes publica aquesta vulnerabilitat, he tingut temps per a mirar-me-la i entendre-la. La veritat és que m’ha costat trobar una bona explicació, ja que no acabava de veure on entrava l’errada en l’especificació del protocol.

Finalment ho he vist clar llegint aquest document:

http://www.g-sec.lu/practicaltls.pdf

Per tal de poder aprofitar aquest bug d’una manera interessant, cal que el protocol de sobre cumpleixi unes característiques molt concretes, ja que lúnic que s’aconsegueix és concatenar contingut de l’atacant just abans del de l’usuari en qüestió. A més, com es porta dient durant tot aquest temps, només es pot aprofitar si podem fer Man In the Middle.

El procediment en mode molt resumit seria el següent:

• L’atacant detecta i bloqueja momentàniament una connexió TLS/SSL (connexió #1).

• Un cop retinguda, inicia una connexió TLS/SSL amb el mateix destí (connexió #2), envia el paquet que vol concatenar i provoca una renegociació.
• Al començar la renegociació, fa de proxy entre el client i el servidor per tal que la negociació inicial del client (connexió #1) coincideixi amb la renegociació del servidor (a nivell de protocol, els passos a seguir per una negociació inicial i per una renegociació són els mateixos).
• Un cop fet això, tenim que el servidor es pensa que totes les dades que ha rebut són del mateix usuari, i les dona com a bones.

Durant el moment en què l’atacant fa de proxy entre el client i el servidor (moment en què el client continua la seva negociació), aquest ha de xifrar amb la clau que ell ha negociat (en la connexió #2) tot el què el client està enviant. Això ho ha de fer perquè una renegocicació s’ha de fer utitlitzant les claus de xifratge utilitzades fins al moment.

Alguna pregunta? 😉