0

I have a MITM setup between a client and a server - the client only supports TLSv1 when it comes to that server and the server support SSLv3 up to TLSv1.2.

There is a vulnerability on the server which only works on SSLv3 connections. Is it possible to convert each and every message between them so the client will view the connection and treat it as TLSv1 while the server as SSLv3? If so, how is that accomplished? If not, what prevents it?

Zach P
  • 131
  • 4

1 Answers1

1

If the client supports only TLSv1 there is no way to force it to use SSLv3 instead. You also cannot tamper with the SSL handshake by replacing the protocols since the handshake itself is protected against tampering.

This leaves only the classical man in the middle attack where there are two SSL connections: one between client and MITM and the other between MITM and server. This attack fails if the client properly validates the certificate snce the MITM cannot provide a certificate which is both issued by a CA trusted by the client and also properly identifies the original server.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Why does the certificate prevent it? Why can't I convert the message to SSLv3 and fit the fields to suit the same values (same certificate, same CA, same application data etc.)? – Zach P Nov 30 '16 at 14:55
  • @ZachP: you need to have the private key of the certificate in order to use it. See http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. – Steffen Ullrich Nov 30 '16 at 16:46
  • Only then? Because as much as I understand I can, for example, convert the TLSv1 message to SSLv3 by changing parts of the header - as the encryption is always the same, no? What actually prevents me from that - because the header itself is unencrypted? Also, is achieving a private key from a modern certificate not realistic? – Zach P Nov 30 '16 at 18:23
  • @ZachP: The header is not encrypted but there is a check at the end that the header was not modified. See [How well is the SSL/TLS handshake protected against modifications?](http://security.stackexchange.com/questions/71979/how-well-is-the-ssl-tls-handshake-protected-against-modifications). – Steffen Ullrich Nov 30 '16 at 21:51
  • Okay, so it is impossible. Even so, how would one go about changing it - assuming that this feature is not implemented on the client end? – Zach P Nov 30 '16 at 22:01
  • @ZachP: If you assume that the TLS stack of the client is broken and does not implement basic security features then you could replace all TLS versions in the ClientHello with SSLv3 and remove all TLS specific extensions (SSLv3 does not have extensions). – Steffen Ullrich Nov 30 '16 at 22:05