Keywords: wget | SSL handshake failure | TLS SNI
Abstract: This article delves into the SSL handshake failure issue encountered when using wget to download resources from HTTPS sites, specifically the OpenSSL error SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure. Through a case study of downloading from Coursera, it reveals that the core problem stems from an outdated wget version lacking support for TLS Server Name Indication (SNI). The paper explains SNI mechanics, the impact of wget version differences, and provides solutions such as upgrading wget, using alternative tools, and debugging methods. It also discusses related SSL/TLS configurations and best practices to help readers comprehensively understand and resolve similar network download issues.
When using wget to download files from HTTPS websites, users often encounter the OpenSSL error: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure, accompanied by the message "Unable to establish SSL connection." This issue typically arises from compatibility problems during the SSL/TLS handshake process, rather than simple certificate verification failures. Based on a specific case study, this article analyzes the root causes in depth and provides systematic solutions.
Problem Background and Error Analysis
A user attempted to download course resources from Coursera (e.g., URL: https://class.coursera.org/matrix-002/lecture), but the wget command failed. The environment included wget-1.13.4 and OpenSSL 1.0.1f. Initial suspicions pointed to missing server or client certificates, but even with the --no-check-certificate option, the problem persisted. Debugging output (wget -v --debug) revealed that the error actually occurred when redirecting to www.coursera.org, not the original URL.
Core Issue: Missing TLS SNI Support
The root cause is an outdated wget version lacking support for TLS Server Name Indication (SNI). SNI is an extension of the TLS protocol that allows clients to specify the server's domain name early in the handshake, crucial for virtual hosts sharing IP addresses. Support for SNI was added starting from wget version 1.14. In older versions, when websites like www.coursera.org require SNI, the handshake fails, triggering the aforementioned OpenSSL error.
Example code demonstrates the debugging process:
$ wget https://class.coursera.org
...
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
...
Location: https://www.coursera.org/ [following]
...
Connecting to www.coursera.org (www.coursera.org)|54.230.46.78|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.
Solutions and Implementation Steps
The primary solution is to upgrade wget to a version that supports SNI (1.14 or higher). On Linux systems, this can be done via package managers, e.g., running sudo apt-get update && sudo apt-get install wget on Ubuntu. After upgrading, retrying the download command usually resolves the handshake failure.
If upgrading is not feasible, consider alternatives: use other tools with SNI support like curl (e.g., curl -O https://class.coursera.org/matrix-002/lecture), or configure OpenSSL to enable legacy protocol fallback (not recommended due to security risks). Additionally, ensure the network environment is free from proxies or firewalls interfering with SSL connections.
In-depth Technical Details and Best Practices
The SSL/TLS handshake involves multiple steps, including protocol version negotiation, cipher suite selection, and certificate verification. SNI is sent in the ClientHello message, enabling the server to return the correct certificate. Modern websites widely use SNI, and incompatibility with old clients leads to handshake failures. It is advisable to regularly update toolchains and use wget -v or openssl s_client -connect for debugging to pinpoint specific error points.
For certificate-related errors, manually specify the certificate path (e.g., wget --ca-certificate=/path/to/cert.pem), but this was not the main issue in this case. Always prioritize HTTPS and verify certificates to ensure data transmission security.