Check EV in certs, add TLS 1.3 support

[konklone]

This adds two new features to the SSLyze scanner:

• Detects TLS 1.3 (draft 23) support on a given host.
• Detects the use (or intended use) of Extended Validation (EV) on certificates served to the client.

To detect TLS 1.3, it's using SSLyze's built-in TLS 1.3 scanner. As of this commit, SSLyze is stuck at 1.3 after #217, so it's detecting an older draft of 1.3. When SSLyze is updated to 1.4 again, it should detect TLS 1.3 draft 23.

To prepare the list of EV OIDs:

• I grabbed MS and Apple EV OIDs from the output of tl-create. tl-create has a bug with Mozilla EV OIDs, and doesn't gather Chrome EV OIDs.
• For Mozilla, I grabbed the Firefox source code and extracted all the EV OIDs (except for the debug ones at the top).
• For Google, I grabbed the Chromium source code and extracted all the EV OIDs.
• I flattened the lists, and then deduped each browser's set of EV OIDs, and put them into Python lists at the bottom of sslyze.py.
• I removed 2.23.140.1.3 from the Microsoft array, which is the EV Code Signing OID.
• I removed 2.23.140.1.1 and put it in its own value. This OID indicates that the certificate is asserting its validation complies with EV guidelines generally, but does not indicate that the CA being used to issue this certificate is trusted for EV in any major browser.

To check for EV status, the code:

• Grabs the set of policy OIDs out of the served leaf certificate, using the Python cryptography library.
• Tests each of them against 2.23.140.1.1 to see if the certificate is asserting itself as EV.
• Tests each of them (except for 2.23.140.1.1) against each browser list, to see which browsers it matches.
• Returns several fields: whether a host is serving a cert asserting to be EV (boolean), whether a host is serving a cert trusted as EV in any of the 4 browsers (boolean), the set of browser-trusted OIDs (string), and the union set of the browsers the given OIDs are trusted in (string).

[fotisl]

I don't think that your EV checking algorithm is correct. By flattening the list of EV OIDs you loose the link to the CA certificate. A simple example that will lead to a problem is the following:

1. Organization xyz has Root CA 'Root1' which is included in Mozilla and Chrome
2. After some time (or some acquisition) they create 'Root2' which shares the same EV OID
3. They apply for inclusion at Mozilla and they are approved
4. They apply for inclusion at Chome and they are denied
   This certificate will appear as EV only at Mozilla, but you will identify it as EV for both Mozilla and Chrome.

[konklone]

Yeah, that's a good point. I think I should probably eliminate the field showing which browsers it's trusted in, since I'm a long way off from validating they are actually trusted in those browsers. I should also change the verbiage around Trusted somewhat, since the presence of a CA-specific OID in these lists is not sufficient to be sure that the OID is actually trusted.

[konklone]

For clarity, this PR is only really trying to help us detect when entites are trying to use EV, not whether they're actually succeeding. I can add some clarifying comments to that effect, too.

[jsf9k]

@konklone I'm currently running a test with all my scanning done in Lambda and with the latest domain-scan code. Once that is successful I'll try upgrading sslyze again to the latest version.

[jsf9k]

I did some tests and this appears to be working great!