Cfrtjryk

I am trying to grab a webpage with curl

$ curl -k https://1.1.1.1/login.html

curl: (35) error:14092105:SSL routines:ssl3_get_server_hello:wrong cipher returned

The error means nothing to me. I have no problem downloading the webpage with firefox. How do I go about debugging the issue?

$ curl -V

curl 7.53.1 (x86_64-pc-linux-gnu) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 (+libicu/58.2) libssh2/1.8.0

Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp

Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy PSL

Please refer: https://stackoverflow.com/questions/34176433/lwp-iosocketssl-fails-with-ssl3-get-server-hellowrong-cipher-returned
You should check SSL, is it using IP or hostname? if it is using hostname best to use hostname instead of IP.

Since I could connect to the server with Firefox, I added the CipherFox add-on. This allowed me to determine the cipher used by Firefox when connecting. In my case it was the cipher was TLS_RSA_WITH_AES_256_CBC_SHA. A little Googling led me to a list of ciphers that suggests that TLS_RSA_WITH_AES_256_CBC_SHA is AES256-SHA. I then simply ahd to tell curl to use the new cipher

curl --ciphers AES256-SHA -k https://1.1.1.1/login.html

As this is a public wifi login portal, I am not worried about security. If you are worried about security, you should probably make sure the cipher you are using is appropriate.

SSL is a complex protocol with many options. The client and the server need to negociate to select compatible options. This is made especially difficult because one of the objectives of SSL is to protect against a man-in-the-middle attack and one of the possible methods of attack is to perturb the negociation — which has to happen before secure communication is established — in order to force insecure parameters.

SSLv3 is an obsolete version of the protocol. Today TLS 1.2 is preferred, 1.0 is ok (as is 1.1, but it's rare in practice). If the negociation goes down to SSLv3, either the server is seriously outdated or something went wrong (probably because the server is badly configured).

A useful tool to get more information about what's going on is Wireshark. Tell it to record TCP traffic to 1.1.1.1 on port 443 with the filter host 1.1.1.1 and port 443. Wireshark should automatically detect the connection as SSL and will display a detailed analysis of each message. In the SSL connection, the client first sends a “client hello” message which indicates what settings it supports, and the server replies with a “server hello” that makes a selection among the client's supported settings. Here it seems that the server has selected something that the client doesn't support, causing a protocol downgrade.

curl -d "submit=accept&buttonClicked=4&err_flag=0&network_name=Guest%20Network" --ciphers AES256-SHA -k -X POST https://1.1.1.1/login.html