I had to configure a newly purchase network KVM, which allows remote control of several servers using the VNC protocol. It had a web interface to configure it and it was enforcing HTTPS, which means that a request to plain HTTP was redirected to HTTPS.
There was only one problem. Whenever I tried to connect, my browser (Firefox of course) would throw a HTTPS handshake error. As I was accessing the KVM via an odd proxy/VPN via web I immediately thought that this middle hardware could be doing some shenanigans.
However after further testing I could confirm that the problem was not this proxy/VPN, as I was also getting an error from a server inside the same network.
curl -vvvk 'https://192.168.1.250/' * Trying 192.168.1.250... * TCP_NODELAY set * Connected to 192.168.1.250 (192.168.1.250) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS alert, Server hello (2): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * stopped the pause stream! * Closing connection 0 curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
This error gave me the clues I needed. What if this new purchased hardware had been shipped with old enough software that its web interface only supported SSLv3, which is nowadays completely deprecated due to the POODLE vulnerability ?
I found that Firefox had disabled SSLv3 support in Firefox 34 so I downloaded a portable version of Firefox 33 and tried to access... and it worked !!
Of course the very first thing I did was to update the firmware and after this I could access from any browser of software.
This will help me remember that when buying new hardware I might still get old vulnerable software.