1

I have a device that functions as a server and uses OpenSSL - it supports SSLv3 and TLS 1.0. That same device also functions as a client to some other servers - I am trying to see if I can downgrade the connection from the device to SSLv3 (a connection to a server which supports SSLv3).

I am having some trouble and I suspect (but am not sure) that the device does not support SSLv3 as a client - only as a server. I have this .pcap capture file uploaded on CloudShark (it's anonymized so 0.0.0.0 is the device, 1.1.1.1 is me - functioning as a MITM and 2.2.2.2 is the server) which shows that when I am trying to simply change the protocol version in the TLS 1.0 handshake to show that SSLv3 is the highest supported I get an error - but not on the server, rather on the device itself!

This was surprising to me and I am wondering if the Handshake Error (40) indicates that the device does not support SSLv3 or maybe some other error that is possible to bypass.

Any knowledge in the subject or way I can go about downgrading the connection will be much appreciated.

Note: The checksum and some other parameters will occur as invalid because I modified the packets to keep the anonymity - so ignore the checksum. Also, in the pcap file the failed interaction is shown multiple times in multiple different tries.

  • it doesn't look like a real SSLv3 ClientHello, the record layer version is TLS1.0 and there are extensions (extensions do not exist in SSLv3). Maybe the other side can't process such a ClientHello. – Z.T. Nov 15 '16 at 8:43
  • @Z.T. What do you mean? The ClientHello is in TLS 1.0 but I am trying to convince the server to decide that the version of the session would be SSLv3 - which seems to have worked. The client should then oblige to the server (at least to my understanding - correct me if I'm wrong) and communicate via SSLv3 but it sends this error instead. – Zach P Nov 15 '16 at 9:02
  • Yeah, the server's reply is fine. I just checked and openssl s_client -connect www.samsungotn.net:443 -servername www.samsungotn.net -ssl3 works. Maybe the client does not expect the server to choose SSLv3 when it offered TLS1.0 and closes the connection because of that? – Z.T. Nov 15 '16 at 9:59
  • @Z.T. It is the possibility I thought of, I hope it's not it - otherwise I cannot see a way for me to downgrade the connection (maybe there is another way but I cannot see it) - even if so, I hope there is the possibility of fooling the client in some way - if you have any idea please let me know. I am assuming that, if it is the case, the client is configured to act as a server which accepts SSLv3 but as a client it doesn't accept SSLv3 - or at least with that specific server for some reason. – Zach P Nov 15 '16 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.