Cause of SSL Handshake Error The SSL Handshake Error occurs if the read access has not been granted to the OS, thus preventing the web server from completing authentication. It indicates that the browser's connection to the web server isn't secure.
If the TLS/SSL handshake succeeds, then the TLS/SSL client and server transfer data to each other securely. Otherwise, if a TLS/SSL handshake failure occurs the connection is terminated and the client receives a 503 Service Unavailable error. The protocol used by the client is not supported by the server.
ApacheBench doesn't seem to be capable of ignoring certificate problems (at least some of them) so I wrote this script:
#!/bin/bash
K=200;
HTTPSA='https://192.168.1.103:443/'
date +%M-%S-%N>wgetres.txt
for (( c=1; c<=$K; c++ ))
do
wget --no-check-certificate --secure-protocol=SSLv3 --spider $HTTPSA
done
date +%M-%S-%N>>wgetres.txt
It's not as precise as AB, but gives the idea. Does well in comparison tests.
httperf is also single threaded, but as of today (Aug 31, 2012), it correctly handles SSL and even has a some useful additional features surrounding SSL:
--ssl Specifies that all communication between httperf and the server should utilize the Secure Sockets Layer (SSL) protocol. This option is available only if httperf was compiled with SSL sup†port enabled. --ssl-ciphers=L This option is only meaningful if SSL is in use (see --ssl option). This option specifies the list L of cipher suites that httperf may use in negotiating a secure connection with the server. If the list contains more than one cipher suite, the ciphers must be separated by a colon. If the server does not accept any of the listed cipher suites, the connection estab†lishment will fail and httperf will exit immediately. If this option is not specified when the --ssl option is present then httperf will use all of the SSLv3 cipher suites provided by the underlying SSL library. --ssl-no-reuse This option is only meaningful if SSL and sessions are in use (see --ssl, --wsess, --wsesslog). When an SSL connection is established the client receives a session identifier (session id) from the server. On subsequent SSL connections, the client normally reuses this session id in order to avoid the expense of repeating the (slow) SSL handshake to establish a new SSL ses†sion and obtain another session id (even if the client attempts to re-use a session id, the server may force the client to rene†gotiate a session). By default httperf reuses the session id across all connections in a session. If the --ssl-no-reuse option is in effect, then httperf will not reuse the session id, and the entire SSL handshake will be performed for each new con†nection in a session.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With