The new RFC 7465 "Prohibiting RC4 Cipher Suites" has been published.

Because of the RC4 deficiencies noted in Section 1, the following apply:

• TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.
• TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in > the ClientHello message.
• If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.»

Source: https://tools.ietf.org/html/rfc7465

So, in my opinion, it's time to give an F for servers using RC4 cipher suites.

The json response for /info includes a clientMaxAssessments field which is missing from the api docs.

Hi Ivan,

In the API docs you have «ocspStapling - true if OCSP stapling is deployed on the server»

But many CA's doesn't have OCSP IPv6 responders.
A nice list (probably outdated) in http://unmitigatedrisk.com/?p=147

So, reggarding this, if the server is:

• only IPv4: 'true' if if server as OCSP stapling is deployed and OCSP responder works with IPv4
• only IPv6: 'true' if if server as OCSP stapling is deployed and OCSP responder works with IPv6
• Dual stack (IPv4/IPv6): 'true' if server as OCSP stapling is deployed AND OCSP responder works with IPv4 and IPv6

Is this the result of the test? or ssl scan test doesn't test IPv6 OCSP?

A similiar case also for CRL in IPv6. For instance if a server is serving IPv6 and has a certificate from a CA with only IPv4 CRL, should this server be considered exceptional?

Also if a server has IPv6 shouldn't the endpoints IPv6 also be in the API JSON result (ex: "ipv6Address")?

Thanks

Either in the --grade option, or in a new --grade-with-errors option, can you include errors e.g. "Unable to connect to server" and "No secure protocols supported"?

e.g. If you input a hostfile and foo.com supports ssl, but foo2.com doesn't the output would currently look like

"foo.com":"A"

but it would be useful to have

"foo.com":"A"
"foo2.com":"No secure protocols supported"

as you are then guaranteed all hosts in the hostfile are shown in the output generated. If you have say 20 hosts and 2 throw errors this is currently hard to spot.

Referring to https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf, servers that support SSL 3 and TLS 1.2 still got a score of 90%, even if they are vulnerable to POODLE (SSLv3).
But if a server does not support TLS 1.2, I got a score of 70%.

Same for RC4: Grade is B, but the score of key exchange can still be 90%. I found a server, that supports deprecated SSL 2 ciphers. Grade is F, because of SSL 2, but cipher strength and key exchange are still 80% and 90%.

Referring to https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf, I also should get a much worse score with 3DES enabled, because it's only 112 bit. So with the current spec I should get a score of 60% (with additional 256 suites enabled). But for the score, 3DES counts still as 168 bit.

When testing a domain that does not exists (ex: asdhasiuddfshasidhais.com) the go script fails, stops and produces no result.

Shouldn't it continue with the list of hosts and add a result of domain not found for that domain in json?

For instance, if you are testing like a list of 50 sites and site 40 does not exists, you have to retest all over again.

I can't find this in the API documentation or the returned results. Any plans to include it?

The API docs are currently in a PDF file, which makes it near impossible to contribute to. More importantly, it is also very difficult to track changes over time, which may be relevant for people building other API clients.

I'm not sure what your workflow is for maintaining that document, and whether converting it to markdown is okay for your ongoing maintenance. But if you're amenable to it, I'd be happy to take an initial stab at the conversion.

# ./ssllabs-scan www.google.com
...
2015/01/29 04:19:22 [ERROR] Too many failed HTTP requests

As a suggestion, shouldn't the use of ChaCha20-Poly1305 and AES GCM as a prefered ciphers considered to obtain an A+ ( or A++ ;) )?

As you know better than i, performance is an important part of https implementations.

As posted in Google Security blog post and Adam Langley in his blog, the performance of ChaCha20-Poly1305 (without special hardware) is pretty good, and it's considered secure.

https://www.imperialviolet.org/2013/10/07/chacha20.html
http://googleonlinesecurity.blogspot.pt/2014/04/speeding-up-and-strengthening-https.html

From my point of view, who configured this ciphers in their servers normally knows what is doing, and so there's a clear effort to have an "exceptional" configuration in terms of security and performance.

As you know, Chacha20-Poly1305 it's not an IETF standard yet, but there is already a rfc draft made by Nir and Langley (https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-03 and http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03)

Daniel J. Bernstein work on ChaCha20 > http://cr.yp.to/chacha/chacha-20080120.pdf

In some cases the API results invalid JSON accoording to the perl library JSON.

E.g.

$ ./ssllabs-scan.pl -h seccubus.com -v -v -v --from-cache
calling info
SSL Labs v1.12.8 (criteria version 2009i)
Maximum number of concurrent assessments: 5
Starting scan of seccubus.com
Calling analyze?host=seccubus.com&all=done&fromCache=on
*** RESPONSE HEADERS ***
Connection : close
Date : Tue, 27 Jan 2015 21:42:09 GMT
Server : Apache
Content-Type : application/json;charset=ISO-8859-1
Client-Aborted : die
Client-Date : Tue, 27 Jan 2015 21:42:49 GMT
Client-Peer : 104.130.202.77:443
Client-Response-Num : 1
Client-SSL-Cert-Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Client-SSL-Cert-Subject : /OU=Domain Control Validated/OU=PositiveSSL/CN=api.dev.ssllabs.com
Client-SSL-Cipher : DHE-RSA-AES256-SHA
Client-SSL-Socket-Class : IO::Socket::SSL
Client-SSL-Warning : Peer certificate not verified
Client-Transfer-Encoding : chunked
Set-Cookie : JSESSIONID=290B2398A7C36B8CF65DF7197FF3B9DF; Path=/; Secure; HttpOnly
Strict-Transport-Security : max-age=31536000
X-ClientMaxAssessments : 5
X-Died : Missing newline after chunk data: 'e":"BingBot",' at /System/Library/Perl/Extras/5.16/Net/HTTP/Methods.pm line 481.
*** RESPONSE DATA ***
{"host":"seccubus.com","port":443,"protocol":"HTTP","isPublic":false,
"status":"READY","startTime":1422393462881,"testTime":1422393606749,
"engineVersion":"1.12.8","criteriaVersion":"2009i","endpoints":[{
"ipAddress":"178.237.34.227","serverName":
"a4091.mcehosting.atom86.net","statusMessage":"Ready","grade":"M",
"hasWarnings":false,"isExceptional":false,"progress":100,"duration":
93366,"eta":24,"delegation":1,"details":{"hostStartTime":
1422393462881,"key":{"size":4096,"alg":"RSA","debianFlaw":false,
"strength":4096},"cert":{"subject":
"1.2.840.113549.1.9.1\u003d#161a706f73746d61737465724073656374696f6e7a65726f2e6f7267,CN\u003dssl.sectionzero.org,C\u003dNL,2.5.4.13\u003d#13105741557563715339456b4745364c4a65",
"commonNames":["ssl.sectionzero.org"],"altNames":[
"ssl.sectionzero.org","sectionzero.org"],"notBefore":
1413388924000,"notAfter":1445029542000,"issuerSubject":
"CN\u003dStartCom Class 1 Primary Intermediate Server CA,OU\u003dSecure Digital Certificate Signing,O\u003dStartCom Ltd.,C\u003dIL",
"sigAlg":"SHA1withRSA","issuerLabel":
"StartCom Class 1 Primary Intermediate Server CA","revocationInfo":
3,"crlURIs":["http://crl.startssl.com/crt1-crl.crl"],"ocspURIs":[
"http://ocsp.startssl.com/sub/class1/server/ca"],
"revocationStatus":2,"sgc":0,"issues":8},"chain":{"certs":[{
"subject":
"1.2.840.113549.1.9.1\u003d#161a706f73746d61737465724073656374696f6e7a65726f2e6f7267,CN\u003dssl.sectionzero.org,C\u003dNL,2.5.4.13\u003d#13105741557563715339456b4745364c4a65",
"label":"ssl.sectionzero.org","issuerSubject":
"CN\u003dStartCom Class 1 Primary Intermediate Server CA,OU\u003dSecure Digital Certificate Signing,O\u003dStartCom Ltd.,C\u003dIL",
"issuerLabel":
"StartCom Class 1 Primary Intermediate Server CA","raw":
"-----BEGIN CERTIFICATE-----\nMIIHZjCCBk6gAwIBAgIDE51oMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE\r\nChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln\r\nbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2\r\nZXIgQ0EwHhcNMTQxMDE1MTYwMjA0WhcNMTUxMDE2MjEwNTQyWjBxMRkwFwYDVQQNExBXQVV1Y3FT\r\nOUVrR0U2TEplMQswCQYDVQQGEwJOTDEcMBoGA1UEAxMTc3NsLnNlY3Rpb256ZXJvLm9yZzEpMCcG\r\nCSqGSIb3DQEJARYacG9zdG1hc3RlckBzZWN0aW9uemVyby5vcmcwggIiMA0GCSqGSIb3DQEBAQUA\r\nA4ICDwAwggIKAoICAQDD3NC+uCEUItP+2Ote59n2Ah3bEQcpf7D2qqRS5NrvUJsVk558YVOPG1Cx\r\n9ORpk9CBp6EfF9Rnnidgn0gXEVJsHttLoyueiT1n0DrL4cLKYdcSGNMhCG51EypVq98VIIbxouqc\r\nwnLHjjdBA4yiZPFpnjMqJLlJjJrh2S3eUixCpWk5rqH+8Oyl36kYVOuju1GlJ2ch14IXdAjVSxjg\r\nnoK4niVrSNAEgQ6iz/byCgLD0e4Zwd2R+u9ujvOstAmGLCQ9HvFcQo/GLPnfc9b1ZOewqZZRKUsW\r\nDt7VaWaF1qBsStU+/10fIjyW72xP6QpiqRXDRM57c+LhhjGpoaTv8rfV9UaW2XYCw1ouEiQShxfn\r\nejTH/rdmyfqQ7baPXdQw5JGjHF7z+Wu0QDh1oVpRxauwGVRwov/yB0s+UCmrFZc3Lg4oUHyXkGuK\r\nEhJpNmfGdEtWXMWmqfb1jvskcMUfP1IkHR7fmDjtwNvH1saQtbkuSqkuLKe6Gy3O3dczwGNypgEx\r\nI10VTZaxWVV7b6C+LnoR/O3lhm8smOzu+gvyqTC4OXAyvOym1CH5O9CDf6QPDu1y82PlUJZhynWv\r\nk5CR2iAMIoD/Txas0HnfXR6a4lglYJALFKov9Ep/J0Z+8CLM5/cU1DjniQ21P8Gj8Ly04Ycxuc8Q\r\nBb1gsybwjgO+INeKuwIDAQABo4IC6TCCAuUwCQYDVR0TBAIwADALBgNVHQ8EBAMCA6gwEwYDVR0l\r\nBAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFDjYnPa4rHIVD2nd9X3zcKsuR1+RMB8GA1UdIwQYMBaA\r\nFOtCNNCYsKuf9BtrCPfMZC7vDixFMC8GA1UdEQQoMCaCE3NzbC5zZWN0aW9uemVyby5vcmeCD3Nl\r\nY3Rpb256ZXJvLm9yZzCCAVYGA1UdIASCAU0wggFJMAgGBmeBDAECATCCATsGCysGAQQBgbU3AQID\r\nMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYI\r\nKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo\r\naXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRh\r\ndGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25s\r\neSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBw\r\nYXJ0eSBvYmxpZ2F0aW9ucy4wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5zdGFydHNzbC5j\r\nb20vY3J0MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz\r\ncC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9zZXJ2ZXIvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h\r\naWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuc2VydmVyLmNhLmNydDAjBgNVHRIEHDAa\r\nhhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAIVe75Qg8U4HimwR\r\n3TGIdvDiUkDFaeO670JlPnaaKW0kZFU3iGhxu7pmBZ0onhb1ZRGC2EBXpz6nRvcBRgnX+wInNgXN\r\nNRWhJ496neZj5EIh47L3LOmrXz0VATZIfw/VQ6hNuKwpZoPzvvcR+GTKjmK4yyn4xlKWNjRtLyaf\r\nlAaD7Lgmdc6xzeMzB65fXYd51eiDdtWgmzUSfycYvh+qSnl1dYo/gH0RNTZHmt7beH1PQqhA4MCq\r\nbqq3IKuaG5UpSr/eJJfx8ZEpmscMM6aGS2zgaPjnSk5XRssi7U/hEc+VKnYjXKNDcSF56AwvilL6\r\n0whsS2Y/p4JRRE0tt+pz2z8\u003d\r\n-----END CERTIFICATE-----\n"}],
"issues":2},"protocols":[{"id":769,"name":"TLS","version":"1.0"},{
"id":770,"name":"TLS","version":"1.1"},{"id":771,"name":"TLS",
"version":"1.2"}],"suites":{"list":[{"id":49199,"name":
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","cipherStrength":128,
"ecdhBits":256,"ecdhStrength":3072},{"id":49200,"name":
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","cipherStrength":256,
"ecdhBits":256,"ecdhStrength":3072},{"id":158,"name":
"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","cipherStrength":128,
"dhStrength":4096,"dhP":512,"dhG":1,"dhYs":512},{"id":159,
"name":"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384","cipherStrength":
256,"dhStrength":4096,"dhP":512,"dhG":1,"dhYs":512},{"id":
49191,"name":"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"cipherStrength":128,"ecdhBits":256,"ecdhStrength":3072},{"id":
49171,"name":"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"cipherStrength":128,"ecdhBits":256,"ecdhStrength":3072},{"id":
49192,"name":"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
"cipherStrength":256,"ecdhBits":256,"ecdhStrength":3072},{"id":
49172,"name":"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"cipherStrength":256,"ecdhBits":256,"ecdhStrength":3072},{"id":
103,"name":"TLS_DHE_RSA_WITH_AES_128_CBC_SHA256",
"cipherStrength":128,"dhStrength":4096,"dhP":512,"dhG":1,
"dhYs":512},{"id":51,"name":
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA","cipherStrength":128,
"dhStrength":4096,"dhP":512,"dhG":1,"dhYs":512},{"id":107,
"name":"TLS_DHE_RSA_WITH_AES_256_CBC_SHA256","cipherStrength":
256,"dhStrength":4096,"dhP":512,"dhG":1,"dhYs":512},{"id":57,
"name":"TLS_DHE_RSA_WITH_AES_256_CBC_SHA","cipherStrength":
256,"dhStrength":4096,"dhP":512,"dhG":1,"dhYs":512}],
"preference":true},"serverSignature":"Apache","prefixDelegation":
false,"nonPrefixDelegation":true,"vulnBeast":true,"renegSupport":2,
"sessionResumption":2,"compressionMethods":0,"supportsNpn":false,
"sessionTickets":1,"ocspStapling":false,"sniRequired":false,
"httpStatusCode":403,"supportsRc4":false,"forwardSecrecy":4,
"rc4WithModern":false,"sims":{"results":[{"client":{"id":56,"name":
"Android","version":"2.3.7","isReference":false},"errorCode":
0,"attempts":1,"protocolId":769,"suiteId":51},{"client":{"id":
58,"name":"Android","version":"4.0.4","isReference":false},
"errorCode":0,"attempts":1,"protocolId":769,"suiteId":49171},{
"client":{"id":59,"name":"Android","version":"4.1.1",
"isReference":false},"errorCode":0,"attempts":1,"protocolId":
769,"suiteId":49171},{"client":{"id":60,"name":"Android",
"version":"4.2.2","isReference":false},"errorCode":0,
"attempts":1,"protocolId":769,"suiteId":49171},{"client":{"id":
61,"name":"Android","version":"4.3","isReference":false},
"errorCode":0,"attempts":1,"protocolId":769,"suiteId":49171},{
"client":{"id":62,"name":"Android","version":"4.4.2",
"isReference":false},"errorCode":0,"attempts":1,"protocolId":
unexpected end of string while parsing JSON string, at character offset 8192 (before "(end of string)") at ./ssllabs-scan.pl line 179.
771,"suiteId":49199},{"client":{"id":41,"nam

In the api docs the Cert.sgc field is described as boolean, but is an integer in the actual json response.

I have a simple script in cron.daily:

#!/bin/bash
/usr/local/bin/ssllabs-scan -grade -usecache=false -hostfile="/usr/local/bin/cert.txt" -quiet=true /tmp/ssllabs-scan.log
cat /tmp/ssllabs-scan.log | sed "s/\"//g" | sort -k2 -r | mutt -s "Qualys SSLLabs check" -- [email protected]
rm /tmp/ssllabs-scan.log

The host file, cert.txt, has 79 hosts that I check. One of those hosts is
webmail.milfordcable.com which originally had a score of 'F'. After
remediation the production web-based Qualys servers score it with a 'B'.
Yet day after day the script shows that it has a score of 'F'.

Why does sslabs-scan output the cached and/or old score?

I don't want to check the host singly using ssllabs-scan because that might
"fix" the issue.

Frank

[Opening issue here as requested by Ivan http://sourceforge.net/p/ssllabs/mailman/message/33042217/]

It might be nice if the API had a "who do you trust today?" call that returned the list of trusted certificates used in validation.

If we run the command with multiple sites in a hosts text file
Ex: go run ssllabs-scan.go -verbosity="error" -usecache="true" -rawoutput="true" -hostfile="hosts.txt" > results.json
The result json as no certificate validation type:
From https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs.md#cert
"validationType - E for Extended Validation certificates; may be null if unable to determine"

When I run "/usr/local/bin/ssllabs-scan -grade -usecache=false -hostfile="/tmp/cert.txt" I get:

2014/11/27 01:00:50 [INFO] Server set max concurrent assessments to 5
2014/11/27 01:00:50 [INFO] SSL Labs v1.10.47 (criteria version 2009i)
2014/11/27 01:00:52 [INFO] Assessment starting: acsnet.com
2014/11/27 01:00:53 [INFO] Assessment starting: amsan.com
2014/11/27 01:00:54 [INFO] Assessment starting: anytimefitness.com
2014/11/27 01:00:55 [INFO] Assessment starting: aop.com
2014/11/27 01:00:56 [INFO] Assessment starting: buydemco.com
2014/11/27 01:01:07 [ERROR] API invocation failed: json: cannot unmarshal number into Go value of type bool
root@node7:/#

If we run the command with multiple sites in a hosts text file
Ex: go run ssllabs-scan.go -verbosity="error" -usecache="true" -rawoutput="true" -hostfile="hosts.txt" > results.json
The result json file has no comma "," between the hosts and because of that is not a valid JSON format.

If we don't use -rawoutput="true" parameter the json file is ok.

The API is not returning the protocols.

The result is this:
"Protocols": {
"Id": 0,
"Name": "",
"Version": "",
"V2SuitesDisabled": false,
"ErrorMessage": false,
"Q": 0
},

The api results doesn't return some information that is in the online version.
I detected this ones:

• Chain certificates: [Signature Algorithm (ex: for SHA1 warnings) | Key ]
• PCI compliant
• FIPS-ready

Scan fails both on the CLI and website stating "No secure protocols supported" despite having SSL configured (albeit horribly configured) for the domain se.rit.edu.

➜  ssllabs-scan git:(rit) ✗ ./ssllabs-scan www.se.rit.edu
2015/01/28 16:58:15 [INFO] Server set max concurrent assessments to 5
2015/01/28 16:58:15 [INFO] SSL Labs v1.12.8 (criteria version 2009i)
2015/01/28 16:58:17 [INFO] Assessment starting: www.se.rit.edu
2015/01/28 17:00:58 [INFO] Assessment complete: www.se.rit.edu (3 hosts in 157 seconds)
    129.21.208.108: Err: No secure protocols supported
    129.21.208.41: Err: No secure protocols supported
    129.21.208.174: Err: No secure protocols supported
[
{"host":"www.se.rit.edu","port":443,"protocol":"HTTP","isPublic":false,
  "status":"READY","startTime":1422482302866,"testTime":1422482460748,
  "engineVersion":"1.12.8","criteriaVersion":"2009i","cacheExpiryTime":
  1422483060748,"endpoints":[{"ipAddress":"129.21.208.108","serverName":
      "freezoid.se.rit.edu","statusMessage":
      "No secure protocols supported","statusDetails":"TESTING_PROTO_3_3",
      "statusDetailsMessage":"Testing TLS 1.2","progress":-1,"duration":
      52541,"eta":-1,"delegation":1,"details":{"hostStartTime":
        1422482302866,"key":{},"cert":{},"chain":{},"protocols":[],"suites":{},
        "prefixDelegation":false,"nonPrefixDelegation":true}},{"ipAddress":
      "129.21.208.41","serverName":"potamus.se.rit.edu","statusMessage":
      "No secure protocols supported","statusDetails":"TESTING_PROTO_3_3",
      "statusDetailsMessage":"Testing TLS 1.2","progress":-1,"duration":
      52543,"eta":-1,"delegation":1,"details":{"hostStartTime":
        1422482302866,"key":{},"cert":{},"chain":{},"protocols":[],"suites":{},
        "prefixDelegation":false,"nonPrefixDelegation":true}},{"ipAddress":
      "129.21.208.174","serverName":"yogi.se.rit.edu","statusMessage":
      "No secure protocols supported","statusDetails":"TESTING_PROTO_3_3",
      "statusDetailsMessage":"Testing TLS 1.2","progress":-1,"duration":
      52539,"eta":-1,"delegation":2,"details":{"hostStartTime":
        1422482302866,"key":{},"cert":{},"chain":{},"protocols":[],"suites":{},
        "prefixDelegation":true,"nonPrefixDelegation":false}}]}

]

2015/01/28 17:00:58 [INFO] All assessments complete; shutting down

When run without any hostnames, very connection to SSL Labs and output the relevant server messages, then show usage instructions. Don't output empty JSON or say that assessments are complete.

e.g., "TestSSLServer.exe" without java.

I don't use Qualys Webservice because it expose server FQDN & result to public.
I will use your service if I can use it locally(offline). Without online is important.

sslscan.exe --scan 10.0.0.1:443

As an API user I would like to grab the HTML report in such a way that it is portalble (hard links to pictures)

Use cases: system broadcast that the server is going down for maintenance, explanation of why a client is blacklisted, new version of the client tool available, etc.

You mentioned the SSLLabs API returns "pretty" JSON. That hasn't been my experience, verified via curl:

curl 'https://api.dev.ssllabs.com/api/fa78d5a4//analyze?host=testing.blahblah.com&all=done&fromCache=on'
{"host":"testing.blahblah.com","port":443,"protocol":"HTTP","isPublic":
  false,"status":"READY","startTime":1415031998142,"testTime":
  1415032072170,"engineVersion":"1.11.8","criteriaVersion":"2009f",
  "endpoints":[{"ipAddress":"512.256.128.64","serverName":
  "blahblah.amazonaws.com","statusMessage":"Ready",
  "grade":"A","hasWarnings":false,"isExceptional":false,"progress":100,
  "duration":74017,"eta":1231,"delegation":1,"details":{"hostStartTime":
    1415031998142,"key":{"size":2048,"alg":"RSA","debianFlaw":false,
      "strength":2048},"cert":{"subject":
      "CN\u003d*.blahblah.com,OU\u003dblahblah,O\u003dblahblah, Inc.,L\u003dblahblah,ST\u003dblahblah,C\u003dUS",
      "commonNames":["*.blahblah.com"],"altNames":[
        "*.blahblah.com","blahblah.com"],"notBefore":1326412800000,

Especially deeper in the structure:

"issues":0},"protocols":{"list":[{"id":768,"name":"SSL","version":
          "3.0"},{"id":769,"name":"TLS","version":"1.0"},{"id":770,
          "name":"TLS","version":"1.1"},{"id":771,"name":"TLS","version":
          "1.2"}]},"suites":{"list":[{"id":49200,"name":
          "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","cipherStrength":256,
          "ecdhBits":256,"ecdhStrength":3072},{"id":49192,"name":
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","cipherStrength":256,
          "ecdhBits":256,"ecdhStrength":3072},{"id":49172,"name":
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","cipherStrength":256,
          "ecdhBits":256,"ecdhStrength":3072},{"id":159,"name":

As an API user I would like to get a "regular" API error reply back in stead of a special error reply for 400 situations.

E.g. testing oops.bla results in:
'oops.bla' => {
'cacheExpiryTime' => '1423124841890',
'protocol' => 'HTTP',
'status' => 'ERROR',
'port' => 443,
'host' => 'oops.bla',
'statusMessage' => 'Unable to resolve domain name',
'startTime' => '1423124781882',
'testTime' => '1423124781890',
'engineVersion' => '1.13.3',
'isPublic' => bless( do{(my $o = 0)}, 'JSON::PP::Boolean' ),
'criteriaVersion' => '2009i'
}

But testing 192.168.10.2 results in:
'errors' => [
{
'message' => 'IP addresses are not allowed',
'field' => 'host'
}
]

In my code I now have to translate the errors object into:

"192.168.10.2" => {
'status' => 'ERROR',
'statusMessage' => 'IP addresses are not allowed',
}

In order for my reporting loop to function normally again.

At the moment, the protocol information doesn't follow the documentation. Instead of a list, it's an object with a list inside. We should remove the extra layer on the server.

Remove the -insecure switch, which skips certificate validation. Replace with an option to specify custom roots. Or perhaps a way to specify the expected certificate fingerprint.

I got the following error on Ubuntu when I try to check any host:
2014/12/09 22:53:14 [ERROR] Too many failed HTTP requests

Linux 3.16.0-25-generic #33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
go version go1.2.1 linux/amd64

Bitmasks are clumsy to handle in higher order languages.

The are used for e.g. certificate issues and revocation information. For my use case a simple text field or array would suffice.

When using

go version go1.4.1 linux/amd64

Linux 3.16.0-28-generic #37-Ubuntu SMP Mon Dec 8 17:15:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

and the command

./ssllabs-scan --quiet --usecache --hostfile hosts.txt > results.json

leads to the result of

2015/01/25 23:28:46 [ERROR] Inconsistent startTime. Expected 1422246482854, got 0.

It would be great, if the test includes a flag, if the checked domain is in the HSTS preload list or not:
https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

Note that the same list is also used by Mozilla Firefox.
The entry request are handled here: https://hstspreload.appspot.com/

Hi Ivan,

I checked the rating guide of the api tests and they are usign version 2009i of the rating guide, but i only see 2009e (https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009e.pdf) in SSL Server Test site. I guess there are also version 2009f, 2009g, 2009h between the two.

Also, is it possible to have an historic of the versions of the rating guide?
Since i'm using it for research porposes i need to know how the grade is obtained at a point in time.

Thanks
André

The way the project is currently structured, it's not really possible to reuse the client portions of the code in a separate tool. The various structs and basic API calling should be moved into a non-main package that can be imported by other code. A lot of projects seem to be following the same pattern of putting the library in the top-level directory, and CLIs under cmd/foo/foo.go.

As a secondary issue, it's generally discouraged having hyphens in the last part of the import path. This is because it's idiomatic for the last segment of the import path to match the package name, and package names can't have hyphens. So maybe rename this so sslscan or something similar? (Alternately, what I did for go-github was to add an additional "github" directory, which does make it longer and a little stuttery)

Assuming that's acceptable, that would all result in a folder structure sort of like:

github.com/ssllabs/sslscan/
  sslscan.go  <-- package sslscan, contains types and general API client
  cmd/
    sslscan/
      sslscan.go  <-- package main, contains the actual CLI and imports the above sslscan package

What do you think?

In the api docs the details field is missing from the Endpoint object description.

In my json result i get some repeated cipher suites... is this normal?
Example:
{"id":10,"name":"TLS_RSA_WITH_3DES_EDE_CBC_SHA","cipherStrength":168}, {"id":10,"name":"TLS_RSA_WITH_3DES_EDE_CBC_SHA","cipherStrength":168}

Because the connection will fail if the client checks the certificate revocation status.

Suggestion, in your next revision, to use the same scale and colors as EC energy labbeling products for faster understanding.
At least in Europe people are already understand the meaning, since they see it everytime they go buy consumer goods.

So A-, A, A+ would became A, A+, A++
See http://ec.europa.eu/energy/efficiency/labelling/labelling_en.htm

Is just an usability suggestion.

At the moment, the client keeps track of how many concurrent assessments there are. This will match the value when there is only one client per IP address, or if there is only one client in a throttling group. It's more efficient to let the server track how many ongoing assessments there are. The client can calculate this by subtracting the value in X-Current-Assessments from X-Max-Assessments.

GOST ciphers are not shown up. It would be interesting to support them, because there is no known vulnerability [1], so they would be a secure alternative to CBC ciphers.

https://www.openssl.org/docs/apps/ciphers.html#gost_ciphersuites_from_draft_chudov_cryptopro_cptls__extending_tls_v1_0
https://tools.ietf.org/id/draft-chudov-cryptopro-cptls-04.txt

[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher

If maxAssessments is set to zero or below that means that the IP address is being blacklisted. There's no point in continuing.

The test should also check if the server sends a content security header.

I propose the following grades if the header is present and valid:
A+ (when there are no other issues) if it allows no resources over http or port 80
C (maybe B) if it allows passive resources over http or port 80
F if it allows active resources over http or port 80

If no CSP header is sent, the grade should not change. Maybe you can't get A+ without.

Why should we have this feature?
This is a good way to prevent mixed content server side.

go version go1.2 amd64

TLSClientConfig: &tls.Config{InsecureSkipVerify: false}

Causes timeouts

./ssllabs-scan -verbosity="trace" ssllabs.com
2014/10/31 10:24:16 [DEBUG] Request (1): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:24:46 [DEBUG] Request (2): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:25:16 [DEBUG] Request (3): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:25:46 [DEBUG] Request (4): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:26:16 [DEBUG] Request (5): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:26:47 [DEBUG] Request (6): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:27:17 [DEBUG] Request (7): https://api.dev.ssllabs.com/api/fa78d5a4//info
2014/10/31 10:27:17 [ERROR] Too many failed HTTP requests

This allows tool programmers to redirect users to the correct SSL labs URL

As an API user I would like to have a better and less hardcoded way of understanding API results.

E.g. the results object now contains a flag isPublic

In the presentation to the user I have to hardcode:

if ( $res->{isPublic} ) {
output -> "The results of this scan are visible to the public at www.ssllabs.com";
}

This also ensures that there is a meachnism to better catch additions to the API output, e. if a new attack was found on SSL (hypothetical and very unlikely ;) I now have a loop like this:

foreach keys in $res {
if ( key that can be ignored ) {

Nothing

} else if ( key I wanna handle ) {

handle it

} else {
print "Unknown new key:" print json output
}

Ivan,

First thanks for your work. It's really great to have a tool like this that will make the web a safer place.
The question i have is: will there be a go script to create a json of the totals like in ssl pulse?

ex: https://www.trustworthyinternet.org/asset/project/ssl-pulse/data/ssl-pulse_2012-04.json

Best reggards,

I expected to see Cert.sgc for "Server gated crypto" but the docs, code and json response contain Cert.scg.

Is this intentional or a typo?

[Opening issue here as requested by Ivan http://sourceforge.net/p/ssllabs/mailman/message/33042217/]

I've been playing with the API a little and one of the things that I think is missing (or, at least, that I'd like to see) is the discovered chain to the root.

I think I read that the backend uses mozilla's trusted roots so I could presumably query some other source for these but that seems clumsy: could the discovered path to the root (if any) be in each response? I understand it shouldn't be part of endpoint_data.details.certs (since these are the chain certificates returned by the server, right?) so perhaps it could be a new attribute of endpoint_data.details`?

Known sites are not being reported on or just not responding, but same sites are reported on via the dev site: https://dev.ssllabs.com

The API results are unclear in how vulnerabilities are shown. For example:
"heartbleed":false
"heartbeat":true
"openSslCcs":1
"poodleTls":1

Having a simply true/false with true being vulnerable would make things easier for consumers.