Git/testssl.sh
1
0
Fork 0
mirror of https://github.com/drwetter/testssl.sh.git synced 2024-12-29 04:49:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

add keys to server defaults, cert start/end time in GMT

Browse Source
This commit is contained in:
Dirk 2018-01-29 23:43:25 +01:00
parent 6d0123d33c
commit 01f7612bd0
3 changed files with 62 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/testssl.1
View File

@ -175,10 +175,7 @@ Any single check switch supplied as an argument prevents testssl\.sh from doing
\fBAnonymous NULL ciphers\fR: \'aNULL:ADH\'
.
.IP "\(bu" 4
\fBExport ciphers\fR (w/o the preceding ones): \'EXPORT:!ADH:!NULL\'
.
.IP "\(bu" 4
\fBLOW\fR (64 Bit + DES ciphers, without EXPORT ciphers): \'LOW:DES:!ADH:!EXP:!NULL\'
\fBExport ciphers\fR (w/o the preceding ones): \'EXPORT:!ADH:!NULL\' * \fBLOW\fR (64 Bit + DES ciphers, without EXPORT ciphers): \'LOW:DES:!ADH:!EXP:!NULL\'
.
.IP "\(bu" 4
\fBWeak 128 Bit ciphers\fR: \'MEDIUM:!aNULL:!AES:!CAMELLIA:!ARIA:!CHACHA20:!3DES\'
@ -201,7 +198,7 @@ Any single check switch supplied as an argument prevents testssl\.sh from doing
\fB\-P, \-\-preference\fR displays the servers preferences: cipher order, with used openssl client: negotiated protocol and cipher\. If there\'s a cipher order enforced by the server it displays it for each protocol (openssl+sockets)\. If there\'s not, it displays instead which ciphers from the server were picked with each protocol (by using openssl only)
.
.P
\fB\-S, \-\-server_defaults\fR displays information from the server hello(s): available TLS extensions, TLS ticket + session information/capabilities and several certificate info including revocation info (CRL, OCSP, OCSP stapling/must staple), Certification Authority Authorization (CAA) record and: trust (CN, SAN, Chain of trust, expiration of certificate)\. For trust chain check there are 4 certificate stores provided (see section \fBFILES\fR below)\. If the trust is confirmed or not confirmed and the same in all four certificate stores there will be only one line of output with the appropriate result\. If there are different results, each store is listed and for the one where there\'s no trust there\'s an indication what the failure is\. Additional certificate stores for e\.g\. an intranet CA an be put into \fBetc/\fR with the extension \fBpem\fR\. In that case there will be a complaint about a missing trust with the other stores, in the opposite case \-\- i\.e\. if trust will be checked against hosts having a certificate issued by a different CA \-\- there will be a complaint by a missing trust in this additional store\. If the server provides no matching record in Subject Alternative Name (SAN) but in Common Name (CN), it will be clearly indicated as this is deprecated\. Possible fingerprinting is possible by the results in TLS clock skew: Only a few servers nowadays still have and TLS/SSL implementation which returns the local clock \fBgmt_unix_time\fR (e\.g\. IIS, openssl < 1\.0\.1f)\. In addition to the HTTP date you could derive that there are different hosts where your TLS and your HTTP request ended \-\- if the time deltas differ significantly\. Also multiple server certificates are being checked for as well as the certificate reply to a non\-SNI (Server Name Indication) client hello to the IP address\.
\fB\-S, \-\-server_defaults\fR displays information from the server hello(s): available TLS extensions, TLS ticket + session information/capabilities, session resumption capabilities, time skew relative to localhost (most server implementations return random values) and several certificate info: certificate signature algorithm, certificate key size, X509v3 key usage and extended key usage, certificate fingerprints and serial, revocation info (CRL, OCSP, OCSP stapling/must staple), certificate transparency info (if provided by server)\. It also displays certificate start and expiration time in GMT\. In addition testssl\.sh checks the trust (CN, SAN, Chain of trust)\. For the trust chain check there are 4 certificate stores provided (see section \fBFILES\fR below)\. If the trust is confirmed or not confirmed and the same in all four certificate stores there will be only one line of output with the appropriate result\. If there are different results, each store is listed and for the one where there\'s no trust there\'s an indication what the failure is\. Additional certificate stores for e\.g\. an intranet CA an be put into \fBetc/\fR with the extension \fBpem\fR\. In that case there will be a complaint about a missing trust with the other stores, in the opposite case \-\- i\.e\. if trust will be checked against hosts having a certificate issued by a different CA \-\- there will be a complaint by a missing trust in this additional store\. If the server provides no matching record in Subject Alternative Name (SAN) but in Common Name (CN), it will be clearly indicated as this is deprecated\. Possible fingerprinting is possible by the results in TLS clock skew: Only a few servers nowadays still have and TLS/SSL implementation which returns the local clock \fBgmt_unix_time\fR (e\.g\. IIS, openssl < 1\.0\.1f)\. In addition to the HTTP date you could derive that there are different hosts where your TLS and your HTTP request ended \-\- if the time deltas differ significantly\. Also multiple server certificates are being checked for as well as the certificate reply to a non\-SNI (Server Name Indication) client hello to the IP address\. Also the Certification Authority Authorization (CAA) record is displayed\.
.
.P
\fB\-x <pattern>, \-\-single\-cipher <pattern>\fR tests matched \fBpattern\fR of ciphers against a server\. Patterns are similar to \fB\-V pattern , \-\-local pattern\fR

34
doc/testssl.1.html
View File

@ -215,8 +215,7 @@ host.example.com:631
<ul>
<li><code>NULL encryption ciphers</code>: 'NULL:eNULL'</li>
<li><code>Anonymous NULL ciphers</code>: 'aNULL:ADH'</li>
<li><code>Export ciphers</code> (w/o the preceding ones): 'EXPORT:!ADH:!NULL'</li>
<li><code>LOW</code> (64 Bit + DES ciphers, without EXPORT ciphers): 'LOW:DES:!ADH:!EXP:!NULL'</li>
<li><code>Export ciphers</code> (w/o the preceding ones): 'EXPORT:!ADH:!NULL' * <code>LOW</code> (64 Bit + DES ciphers, without EXPORT ciphers): 'LOW:DES:!ADH:!EXP:!NULL'</li>
<li><code>Weak 128 Bit ciphers</code>: 'MEDIUM:!aNULL:!AES:!CAMELLIA:!ARIA:!CHACHA20:!3DES'</li>
<li><code>3DES Ciphers</code>: '3DES:!aNULL:!ADH'</li>
<li><code>High grade Ciphers</code>: 'HIGH:!NULL:!aNULL:!DES:!3DES:!AESGCM:!CHACHA20:!AESGCM:!CamelliaGCM:!AESCCM8:!AESCCM'</li>
@ -228,8 +227,35 @@ host.example.com:631
<p><code>-P, --preference</code> displays the servers preferences: cipher order, with used openssl client: negotiated protocol and cipher. If there's a cipher order enforced by the server it displays it for each protocol (openssl+sockets). If there's not, it displays instead which ciphers from the server were picked with each protocol (by using openssl only)</p>
<p><code>-S, --server_defaults</code> displays information from the server hello(s): available TLS extensions, TLS ticket + session information/capabilities and several certificate info including revocation info (CRL, OCSP, OCSP stapling/must staple), Certification Authority Authorization (CAA) record and: trust (CN, SAN, Chain of trust, expiration of certificate). For trust chain check there are 4 certificate stores provided (see section <code>FILES</code> below). If the trust is confirmed or not confirmed and the same in all four certificate stores there will be only one line of output with the appropriate result. If there are different results, each store is listed and for the one where there's no trust there's an indication what the failure is. Additional certificate stores for e.g. an intranet CA an be put into <strong>etc/</strong> with the extension <strong>pem</strong>. In that case there will be a complaint about a missing trust with the other stores, in the opposite case -- i.e. if trust will be checked against hosts having a certificate issued by a different CA -- there will be a complaint by a missing trust in this additional store.
If the server provides no matching record in Subject Alternative Name (SAN) but in Common Name (CN), it will be clearly indicated as this is deprecated. Possible fingerprinting is possible by the results in TLS clock skew: Only a few servers nowadays still have and TLS/SSL implementation which returns the local clock <code>gmt_unix_time</code> (e.g. IIS, openssl &lt; 1.0.1f). In addition to the HTTP date you could derive that there are different hosts where your TLS and your HTTP request ended -- if the time deltas differ significantly. Also multiple server certificates are being checked for as well as the certificate reply to a non-SNI (Server Name Indication) client hello to the IP address.</p>
<p><code>-S, --server_defaults</code> displays information from the server hello(s):
available TLS extensions, TLS ticket + session information/capabilities, session resumption
capabilities, time skew relative to localhost (most server implementations
return random values) and several certificate info: certificate signature algorithm,
certificate key size, X509v3 key usage and extended key usage, certificate
fingerprints and serial, revocation info (CRL, OCSP, OCSP
stapling/must staple), certificate transparency info (if provided by
server). It also displays certificate start and expiration time in GMT.
In addition testssl.sh checks the trust (CN, SAN, Chain of trust). For the trust chain
check there are 4 certificate stores provided (see section <code>FILES</code> below). If
the trust is confirmed or not confirmed and the same in all four certificate
stores there will be only one line of output with the appropriate result. If
there are different results, each store is listed and for the one where there's
no trust there's an indication what the failure is. Additional certificate
stores for e.g. an intranet CA an be put into <strong>etc/</strong> with the extension
<strong>pem</strong>. In that case there will be a complaint about a missing trust with the
other stores, in the opposite case -- i.e. if trust will be checked against
hosts having a certificate issued by a different CA -- there will be a
complaint by a missing trust in this additional store. If the server provides
no matching record in Subject Alternative Name (SAN) but in Common Name (CN),
it will be clearly indicated as this is deprecated. Possible fingerprinting is
possible by the results in TLS clock skew: Only a few servers nowadays still
have and TLS/SSL implementation which returns the local clock <code>gmt_unix_time</code>
(e.g. IIS, openssl &lt; 1.0.1f). In addition to the HTTP date you could derive
that there are different hosts where your TLS and your HTTP request ended -- if
the time deltas differ significantly. Also multiple server certificates are
being checked for as well as the certificate reply to a non-SNI (Server Name
Indication) client hello to the IP address.
Also the Certification Authority Authorization (CAA) record is displayed.</p>
<p><code>-x &lt;pattern>, --single-cipher &lt;pattern></code> tests matched <code>pattern</code> of ciphers against a server. Patterns are similar to <code>-V pattern , --local pattern</code></p>

34
doc/testssl.1.md
View File

@ -138,8 +138,7 @@ Any single check switch supplied as an argument prevents testssl.sh from doing a
* `NULL encryption ciphers`: 'NULL:eNULL'
* `Anonymous NULL ciphers`: 'aNULL:ADH'
* `Export ciphers` (w/o the preceding ones): 'EXPORT:!ADH:!NULL'
* `LOW` (64 Bit + DES ciphers, without EXPORT ciphers): 'LOW:DES:!ADH:!EXP:!NULL'
* `Export ciphers` (w/o the preceding ones): 'EXPORT:!ADH:!NULL' * `LOW` (64 Bit + DES ciphers, without EXPORT ciphers): 'LOW:DES:!ADH:!EXP:!NULL'
* `Weak 128 Bit ciphers`: 'MEDIUM:!aNULL:!AES:!CAMELLIA:!ARIA:!CHACHA20:!3DES'
* `3DES Ciphers`: '3DES:!aNULL:!ADH'
* `High grade Ciphers`: 'HIGH:!NULL:!aNULL:!DES:!3DES:!AESGCM:!CHACHA20:!AESGCM:!CamelliaGCM:!AESCCM8:!AESCCM'
@ -150,8 +149,35 @@ Any single check switch supplied as an argument prevents testssl.sh from doing a
`-P, --preference` displays the servers preferences: cipher order, with used openssl client: negotiated protocol and cipher. If there's a cipher order enforced by the server it displays it for each protocol (openssl+sockets). If there's not, it displays instead which ciphers from the server were picked with each protocol (by using openssl only)
`-S, --server_defaults` displays information from the server hello(s): available TLS extensions, TLS ticket + session information/capabilities and several certificate info including revocation info (CRL, OCSP, OCSP stapling/must staple), Certification Authority Authorization (CAA) record and: trust (CN, SAN, Chain of trust, expiration of certificate). For trust chain check there are 4 certificate stores provided (see section `FILES` below). If the trust is confirmed or not confirmed and the same in all four certificate stores there will be only one line of output with the appropriate result. If there are different results, each store is listed and for the one where there's no trust there's an indication what the failure is. Additional certificate stores for e.g. an intranet CA an be put into __etc/__ with the extension __pem__. In that case there will be a complaint about a missing trust with the other stores, in the opposite case -- i.e. if trust will be checked against hosts having a certificate issued by a different CA -- there will be a complaint by a missing trust in this additional store.
If the server provides no matching record in Subject Alternative Name (SAN) but in Common Name (CN), it will be clearly indicated as this is deprecated. Possible fingerprinting is possible by the results in TLS clock skew: Only a few servers nowadays still have and TLS/SSL implementation which returns the local clock `gmt_unix_time` (e.g. IIS, openssl < 1.0.1f). In addition to the HTTP date you could derive that there are different hosts where your TLS and your HTTP request ended -- if the time deltas differ significantly. Also multiple server certificates are being checked for as well as the certificate reply to a non-SNI (Server Name Indication) client hello to the IP address.
`-S, --server_defaults` displays information from the server hello(s):
available TLS extensions, TLS ticket + session information/capabilities, session resumption
capabilities, time skew relative to localhost (most server implementations
return random values) and several certificate info: certificate signature algorithm,
certificate key size, X509v3 key usage and extended key usage, certificate
fingerprints and serial, revocation info (CRL, OCSP, OCSP
stapling/must staple), certificate transparency info (if provided by
server). It also displays certificate start and expiration time in GMT.
In addition testssl.sh checks the trust (CN, SAN, Chain of trust). For the trust chain
check there are 4 certificate stores provided (see section `FILES` below). If
the trust is confirmed or not confirmed and the same in all four certificate
stores there will be only one line of output with the appropriate result. If
there are different results, each store is listed and for the one where there's
no trust there's an indication what the failure is. Additional certificate
stores for e.g. an intranet CA an be put into __etc/__ with the extension
__pem__. In that case there will be a complaint about a missing trust with the
other stores, in the opposite case -- i.e. if trust will be checked against
hosts having a certificate issued by a different CA -- there will be a
complaint by a missing trust in this additional store. If the server provides
no matching record in Subject Alternative Name (SAN) but in Common Name (CN),
it will be clearly indicated as this is deprecated. Possible fingerprinting is
possible by the results in TLS clock skew: Only a few servers nowadays still
have and TLS/SSL implementation which returns the local clock `gmt_unix_time`
(e.g. IIS, openssl < 1.0.1f). In addition to the HTTP date you could derive
that there are different hosts where your TLS and your HTTP request ended -- if
the time deltas differ significantly. Also multiple server certificates are
being checked for as well as the certificate reply to a non-SNI (Server Name
Indication) client hello to the IP address.
Also the Certification Authority Authorization (CAA) record is displayed.
`-x <pattern>, --single-cipher <pattern>` tests matched `pattern` of ciphers against a server. Patterns are similar to `-V pattern , --local pattern`