This table contains the list of all web sites supporting the SSL protocol. The complete record set is update each month with up to date ip addresses and server types, as well as crypographic data consisting of support protocols, ciphers, the SSL certificate and the certificate issuer.

After our Web Sites data, this is our next oldest continuously updated data set, with the original data collected in April, 1998, and updated every month since then. Our survey report archive features web server survey reports dating back to June 1st, 1998 based on this data.

Name	Type	Description
hostname	varchar(80)	The hostname of the web site as originally found by our web spiders.
domain	varchar(80)	The domain name of the site, derived from the hostname. This may be the same as the hostname.
port	int	The port number on which the web site's HTTP service resides. A value of -1 indicates the default of 80
ipaddr	varchar(15)	The IP address of the web server. If multiple IP addresses are returned when resolving the hostname, this will be the first IP address.
servertype	varchar(255)	The server signature string, as determined via the "Server:" HTTP header line.
jtime	varchar(13)	The julian timestamp. For historical reasons, represented in milliseconds, but the last 3 digits are currently always set 0.
protocol	varchar(20)	A comma separate list of support protocols. Possible values in the list are limited to "SSLv2", "SSLv3", and "TLSv1". A typical field value might be "SSLv3,TLSv1".
cert	varchar(8192)	The SSL certificate.
ciphers	varchar(1024)	A comma separated list of supported ciphers, determined when connecting to the SSL server using the SSLv2 protocol. An example value might be "RC4-MD5,EXP-RC4-MD5,RC2-CBC-MD5,EXP-RC2-CBC-MD5,DES-CBC-MD5,DES-CBC3-MD5"
certorg	varchar(1024)	The certificate issuer, extracted from the x509 certificate "issuer" field.

hostname + port

domain
port
ipaddr
servertype

Data collection is broken down into two distinct phases. Phase 1 consists of IP address resolution of all known hosts. Phase 2 consists of contacting the remote servers 3 times in order to collect server signature strings and to determine which of the SSLv2, SSLV3, and TLSv1 protocols are supported. This two phase process is done because in many cases hostnames will share a web server on a common IP address. Phase 1 allows us to identify all distinct IP addresses which can subsequently be contacted once and only once for the server signature.

When the web server is contacted, a "GET /robots.txt" HTTP 1.0 protocol request is issued.

Each web site in the database is processed in the above fashion each month.

The two phase data collection approach means that there is a lag of about one day between the IP address resolution phase and the signature collection phase. If a web site changes its IP address during this interval, there can be mismatch of the IP address resolved in phase 1, with the actual IP address of the site when the signature string is retrieved from the server as reported by jtime.

The "ciphers" field only contains data for servers supporting the SSLv2 connection. This is because to make a determination of which ciphers are supported for SSLv3/TLSv1 would require making one unique connection attempt for each possible cipher, whereas SSLv2 enabled servers will provide all supported ciphers as part of the initial connection setup.

Field ipaddr can have the special value of NO_RESOLVE implying no name resolution could be done

Field servertype can have the special values of NO_RESOLVE implying no name resolution could be done, or NO_CONTACT if a server response could not be obtained when issuing an HTTP GET request.

At the start of each month, a fresh table with nil data values is created. At that point in time, new hosts not already in the table are added, while sites that were non-responsive for the previous 3 months (sexpired) are removed.