General Description

Pidgin doesn't currently do any certificate verification for SSL. In order to properly do this and ensure security, a certificate manager (something like Mozilla's) needs to be added.

This is William Ehlhardt's project for Summer of Code

Branch

im.pidgin.soc.2007.certmgr

Handy-dandy overview

SSL: The Connection Process

1. purple_ssl_connect called
2. ???

CertificateScheme? API

• Closely modeled on Cipher API

struct Certificate

• CertificateScheme? * scheme
• Internal data

struct CertificateScheme?

Will be registered into an internal list of scheme types

• char * name = "x509", "pgp", etc.
• int ref - for reference counting
• Certificate * import_certificate(file arguments) -
• export_certificate(filename?)
• gboolean check_signature(Certificate * certificate, Certificate * signer) - returns whether one certificate is signed by another
• CertificateVerificationData? * get_verification_data() - returns a structure containing things to show to the user to check the certificate's validity
• 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)

Key Store

The API for this hasn't been decided yet. However, the organization will look something like this: ~/.purple/certificates/cert_scheme_name/cert_unique_id(.pem?) So an example X.509 certificate might be stored as: ~/.purple/certificates/x509/gmail_com_1234567890abcdef1234567890abcdef.pem Some metadata may be necessary for each certificate.

Miscellaneous API changes

• Jabber (and possibly other protocols) use purple_ssl_connect_fd to create SSL connections, throwing out possibly important data about the other end of the connection (hostname, port number) in the process. In the interests of keeping this data intact, I propose adding a purple_ssl_connect_proxyconn that will create an SSL connection around a previously existing ProxyConnection? instead of ripping out its file descriptor and starting anew.

Issues

• Jabber (and possibly others) use the purple_ssl_connect_fd function to build an SSL connection over a previously existing ProxyConnection?. Since all the SSL side sees is the file descriptor in this case, hostname verification is impossible. (29 May)
• talk.google.com gives back a gmail.com certificate?! (29 May)

Resolved Issues

• It looks like PKCS12 (the certificate import/export format) is supported by both libNSS and GnuTLS.

TODO

• General paranoia
• Look at how the SILC prpl does its key management, especially the organization of the API used to check certs and interact with the user to verify them.
• Add some way of passing useful error messages back up out of the SSL interface (23 May)
• Fix purple_ssl_init in sslconn.c; it doesn't do anything (23 May)
  • Talking to nosnilmot suggests that this ought to just be removed outright (24 May)
• Figure out libNSS everything. (25 May)
• Why am I getting single-byte serial numbers from servers? (25 May)
• Work out how to use Glib functions for time checking on certificates. (29 May)
• Stall the timeouts on the TCP connection while waiting for user input on SSL? (29 May)
• Worry about ensuring that plugins don't kill in-use ciphers/certschemes when unloaded? (29 May)

Tasks done

• Figure out how to get key fingerprints out of GnuTLS (25 May, 25 May))

Status

29 May 2007

With some prodding from Ethan, a lot of stuff came together for me design-wise today. I got a substantial part of the API changes laid out.

25 May 2007

Divergence point reached. With the addition of purple_base16_encode_chunked, my changes will force at least a minor version increment. Slapped some code into the GnuTLS SSL plugin and looked at the certificate characteristics coming back. But why am I getting single-byte serial number values back? How large should these serial numbers be?

23 May 2007

Using "Document the SSL interface as it exists now" as an excuse to build a branch and learn Doxygen

17 May 2007

Reading documentation. Lots of it.