| 12 | | 2. ??? |
| | 12 | 2. ssl_connect looks up the "x509" CertificateScheme, making sure that it is loaded |
| | 13 | 3. ssl_connect fetches a the host's certificate |
| | 14 | 4. ssl_connect asks the "tls_peers" CertificateAuthorizer for verification of the certificate. |
| | 15 | 5. The tls_peers CertificateAuthorizer sees if the get_unique_id(cert) can be found within the pool "tls_servers". If so, the certificate is considered Authenticated, and control returns to ssl_connect, which proceeds to the Hostname Check. |
| | 16 | 6. If the certificate cannot be found in the "tls_servers" pool, the tls_peers Authorizer then checks the "tls_ca" pool to see if the certificate chain (using get_signer_unique_id(cert)) leads to any certificates in the "tls_ca" pool. If it does find such a certificate, it uses the check_signature function to verify the signature chain, and if THAT passes, control returns to ssl_connect, which proceeds to the Hostname Check. |
| | 17 | 7. If the tls_peers CertAuthorizer finds an invalid (apparently attempted forged) signature, the connection fails and the user is given a popup detailing the reason. |
| | 18 | 8. If the tls_peers CertAuthorizer fails to find any appropriate signers in the "tls_ca" or "tls_servers" pool, the user is prompted with the certificate details given by get_verification_data. If the certificate passes user prompting, tls_peers->bless_certificate is called. |
| | 19 | 9. If tls_peers finds an expired certificate or any other problem, the connection is aborted with an error. |
| | 20 | 10. We shouldn't get to step 10. |
| | 21 | |
| | 22 | === Hostname Check === |
| | 23 | (some logic needs to be changed here to ensure that we don't prompt every connect for incorrect CN fields) |
| | 24 | 1. ssl_connect checks that the certificate Common Name matches the hostname being connected to. If it matches, it completes the connection initialization. The hostname check may not always work, though, so: |
| | 25 | 2. If the hostname check fails, ssl_connect will prompt the user with the certificate data and a warning that the hostname check failed. |
| | 26 | 3. If the user authorizes the certificate anyways, ssl_connect calls bless_certificate in the tls_peers CertificateAuthorizor, which adds it to the "tls_peers" pool. The connection initialization is then completed. (The exact action at this step is not really laid in stone, though) |
| | 27 | |
| 26 | | * CertificateVerificationData * get_verification_data() - returns a structure containing things to show to the user to check the certificate's validity |
| 27 | | * gchar * fingerprint_sha1, gchar * fingerprint_md5 - return various hashes of the key (named separately as the hash type controls of the CertScheme backends are not supposed to be exposed directly) |
| | 41 | * (some_tuple_list_type) get_verification_data() - returns a list of key-value pairs containing things to show to the user to check the certificate's validity. It's not ''strictly'' key-value due to i18n concerns, but here is an example: [ ("fpr_sha1","0123456789abcdef0123456789abcdef",_("SHA1 Fingerprint")), ("common_name","gmail.com",_("Common Name")), NULL ] |
| | 42 | * char * get_unique_id - returns a string (probably something involving a key fingerprint) that can usefully be used to uniquely identify this certificate (for storage purposes) |
| | 43 | * char * get_signer_unique_id - returns a unique identifier for the key used to sign the certificate |
| | 44 | |
| | 45 | == SslOps Additions == |
| | 46 | * get_peer_certificates - fetches as much of the certificate chain as the peer is willing to provide off of the wire and exports the certificates as several "x509" Certificate instances. |
