Merge pull request #1668 from drwetter/1657_polish

Polish STARTTLS rating output

doc/testssl.1

@@ -638,7 +638,7 @@ This program has a near\-complete implementation of SSL Labs\'s \'SSL Server Rat
 This is \fInot\fR a 100% reimplementation of the SSL Lab\'s SSL Server Test \fIhttps://www\.ssllabs\.com/ssltest/analyze\.html\fR, but an implementation of the above rating specification, slight discrepancies may occur\. Please note that for now we stick to the SSL Labs rating as good as possible\. We are not responsible for their rating\. Before filing issues please inspect their Rating Guide\.
 .
 .P
-Disclaimer: Having a good grade is \fBNOT\fR necessarily equal to having good security! Don\'t start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it\.
+Disclaimer: Having a good grade is \fBNOT\fR necessarily equal to having good security! Don\'t start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it\. Please note STARTTLS always results in a grade cap to T\. Anything else would lead to a false sense of security \- at least until we test for DANE or MTA-STS\.
 .
 .P
 As of writing, these checks are missing: * GOLDENDOODLE \- should be graded \fBF\fR if vulnerable * Insecure renegotiation \- should be graded \fBF\fR if vulnerable * Padding oracle in AES\-NI CBC MAC check (CVE\-2016\-2107) \- should be graded \fBF\fR if vulnerable * Sleeping POODLE \- should be graded \fBF\fR if vulnerable * Zero Length Padding Oracle (CVE\-2019\-1559) \- should be graded \fBF\fR if vulnerable * Zombie POODLE \- should be graded \fBF\fR if vulnerable * All remaining old Symantec PKI certificates are distrusted \- should be graded \fBT\fR * Symantec certificates issued before June 2016 are distrusted \- should be graded \fBT\fR * ! A reading of DH params \- should give correct points in \fBset_key_str_score()\fR * Anonymous key exchange \- should give \fB0\fR points in \fBset_key_str_score()\fR * Exportable key exchange \- should give \fB40\fR points in \fBset_key_str_score()\fR * Weak key (Debian OpenSSL Flaw) \- should give \fB0\fR points in \fBset_key_str_score()\fR
@@ -650,10 +650,10 @@ To implement a new grading cap, simply call the \fBset_grade_cap()\fR function,
 When implementing a new check (be it vulnerability or not) that sets grade caps, the \fBset_rating_state()\fR has to be updated (i\.e\. the \fB$do_mycheck\fR variable\-name has to be added to the loop, and \fB$nr_enabled\fR if\-statement has to be incremented)
 .
 .P
-The \fBset_rating_state()\fR automatically disables ratinng, if all the required checks are \fInot\fR enabled\. This is to prevent giving out a misleading or wrong grade\.
+The \fBset_rating_state()\fR automatically disables rating, if all the required checks are \fInot\fR enabled\. This is to prevent giving out a misleading or wrong grade\.
 .
 .P
-When a new revision of the rating specification comes around, the following has to be done: * New grade caps has to be either: 1\. Added to the script wherever relevant, or 2\. Added to the above list of missing checks (if \fIi\.\fR is not possible) * New grade warnings has to be added wherever relevant * The revision output in \fBrun_rating()\fR function has to updated
+When a new revision of the rating specification comes around, the following has to be done: * New grade caps has to be either: 1\. Added to the script wherever relevant, or 2\. Added to the above list of missing checks (if above is not possible) * New grade warnings has to be added wherever relevant * The revision output in \fBrun_rating()\fR function has to updated
 .
 .SH "EXAMPLES"
 .

doc/testssl.1.html

@@ -484,7 +484,7 @@ Rating automatically gets disabled, to not give a wrong or misleading grade, whe
 
 <p>This is <em>not</em> a 100% reimplementation of the <a href="https://www.ssllabs.com/ssltest/analyze.html">SSL Lab's SSL Server Test</a>, but an implementation of the above rating specification, slight discrepancies may occur. Please note that for now we stick to the SSL Labs rating as good as possible. We are not responsible for their rating. Before filing issues please inspect their Rating Guide.</p>
 
-<p>Disclaimer: Having a good grade is <strong>NOT</strong> necessarily equal to having good security! Don't start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it.</p>
+<p>Disclaimer: Having a good grade is <strong>NOT</strong> necessarily equal to having good security! Don't start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it. Please note STARTTLS always results in a grade cap to T. Anything else would lead to a false sense of security - at least until we test for DANE or MTA-STS.</p>
 
 <p>As of writing, these checks are missing:
 * GOLDENDOODLE - should be graded <strong>F</strong> if vulnerable
@@ -515,7 +515,7 @@ set_grade_warning "Documentation is always right"
 
 <p>When implementing a new check (be it vulnerability or not) that sets grade caps, the <code>set_rating_state()</code> has to be updated (i.e. the <code>$do_mycheck</code> variable-name has to be added to the loop, and <code>$nr_enabled</code> if-statement has to be incremented)</p>
 
-<p>The <code>set_rating_state()</code> automatically disables ratinng, if all the required checks are <em>not</em> enabled.
+<p>The <code>set_rating_state()</code> automatically disables rating, if all the required checks are <em>not</em> enabled.
 This is to prevent giving out a misleading or wrong grade.</p>
 
 <h4 id="Implementing-a-new-revision">Implementing a new revision</h4>
@@ -523,7 +523,7 @@ This is to prevent giving out a misleading or wrong grade.</p>
 <p>When a new revision of the rating specification comes around, the following has to be done:
 * New grade caps has to be either:
   1. Added to the script wherever relevant, or
-  2. Added to the above list of missing checks (if <em>i.</em> is not possible)
+  2. Added to the above list of missing checks (if above is not possible)
 * New grade warnings has to be added wherever relevant
 * The revision output in <code>run_rating()</code> function has to updated</p>
 

doc/testssl.1.md

@@ -392,7 +392,8 @@ This program has a near-complete implementation of SSL Labs's '[SSL Server Ratin
 
 This is *not* a 100% reimplementation of the [SSL Lab's SSL Server Test](https://www.ssllabs.com/ssltest/analyze.html), but an implementation of the above rating specification, slight discrepancies may occur. Please note that for now we stick to the SSL Labs rating as good as possible. We are not responsible for their rating. Before filing issues please inspect their Rating Guide.
 
-Disclaimer: Having a good grade is **NOT** necessarily equal to having good security! Don't start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it.
+Disclaimer: Having a good grade is **NOT** necessarily equal to having good security! Don't start a competition for the best grade, at least not without monitoring the client handshakes and not without adding a portion of good sense to it. Please note STARTTLS always results in a grade cap to T. Anything else
+would lead to a false sense of security - at least until we test for DANE or MTA-STS.
 
 As of writing, these checks are missing:
 * GOLDENDOODLE - should be graded **F** if vulnerable

testssl.sh

@@ -20802,7 +20802,7 @@ run_rating() {
      pr_headlineln " Rating (experimental) "
      outln
 
-     [[ -n "$STARTTLS_PROTOCOL" ]] && set_grade_cap "T" "Encryption via STARTTLS is not mandatory (opportunistic). This leads to a false sense of security"
+     [[ -n "$STARTTLS_PROTOCOL" ]] && set_grade_cap "T" "Encryption via STARTTLS is not mandatory (opportunistic)."
 
      # Sort the reasons. This is just nicer to read in genereal
      IFS=$'\n' sorted_reasons=($(sort -ru <<<"${GRADE_CAP_REASONS[*]}"))