ECDSA support

[tomato42]

• parsing ECDSA certificates
• verifying ECDSA signatures on Server Key Exchange
• negotiating ECDSA ciphers as a client
• loading private keys
• signing Server Key Exchange messages with ECDSA
• negotiating ECDSA ciphers as a server
• handling ECDSA in Certificate Verify (as client and server)
• handling ECDSA in TLS 1.1 and earlier (signatures use SHA1, not SHA1+MD5)
• using m2crypto for ECDSA (can be moved to a separate issue, should autodetect if the version of m2crypto/openssl does support ECC)
  • moved to Accelerate ECDSA/ECDHE #367
• verify that sha1+ecdsa is selected if client didn't advertise signature algorithms but did advertise ecdsa ciphersuites in TLSv1.2
• verify that sha1+ecdsa and sha224+ecdsa is ignored for signature algorithms in TLS 1.3 (it's disallowed there)
• select signature algorithm based on public key type in TLS 1.3 (sha256 can be used with P-256 only, etc.)
• support for starting server with multiple certificates/keys and selecting good one based on client preference, supported cipher suites or signature algorithms
  • (partially: see Select certificate based on curves and ciphers too #366)
• verify that server advertised support for ecdsa_sign in CertificateRequest (or rsa_sign if we have a RSA certificate)
• test coverage for all of the above

fixes #52

merged as #359, #360, #361, #363

---

This change is 

[tomato42]

This is the basic code to make it usable, but it's not really feature complete: certificate selection won't work in TLS 1.1 or earlier. It will give certificate with curve not supported by client. Those issues are tracked in #366 – fixing it would require significant reworking of negotiation and I'd rather close other outstanding PRs than work on polishing this stuff. Fixing #366 should make the code in tlsconnection.py much nicer.

While I did add configuration for virtual hosts, I didn't implement it, just provided a draft for the API. Continuation of that work is in #368.

it is also pure-python, while we could use m2crypto to speed it up, this was moved to #367

[ueno]

---

tlslite/tlsconnection.py, line 3118 at r6 (raw file):

        sni_ext = clientHello.getExtension(ExtensionType.server_name)
        if sni_ext:
            name = sni_ext.hostNames[0].decode('ascii', 'strict')

would it make sense to catch the exception?

[ueno]

---

tlslite/x509.py, line 55 at r9 (raw file):

        return self.bytes == other.bytes

    def __ne__(self, other):

Is this needed? The documentation says that the default implementation diverts to __eq__.

[ueno]

Reviewed 1 of 1 files at r1, 2 of 2 files at r2, 1 of 1 files at r3, 1 of 1 files at r4, 1 of 1 files at r5, 1 of 1 files at r6, 1 of 1 files at r7, 1 of 1 files at r8, 3 of 3 files at r9, 2 of 2 files at r10, 1 of 1 files at r11.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @tomato42)

[tomato42]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @ueno)

---

tlslite/tlsconnection.py, line 3118 at r6 (raw file):

Previously, ueno (Daiki Ueno) wrote…

would it make sense to catch the exception?

no, it was already validated as decodable before

---

tlslite/x509.py, line 55 at r9 (raw file):

Previously, ueno (Daiki Ueno) wrote…

Is this needed? The documentation says that the default implementation diverts to __eq__.

LGTM complained until I added them, maybe it's needed for earlier versions?