PDA

View Full Version : ClanLib 3.0 TLS Support



rombust
03-31-2013, 08:30 PM
Something that concerns me a lot is ClanLib's support of TLS (Transport Layer Security)

The current state of play is that ClanLib can connect to google TLS (encrypted.google.com) and retrieve a page. (See Tests/Network/TLS

At the moment ClanLib can't act as a TLS server. There is not much different between a client and server, it just has not been coded.

We have all the AES and SHA functions. These are completed. (Although they could be optimised using intrinsics)

The function: "void X509_Impl::parse_tbs_certificate(ASN1 &asn1)" parses the certificate, but does not validate it.

This makes ClanLib's TLS security pointless :) A rouge site could pass a fake certificate pretending to be the target server.

We have a couple of options:
1) Use NSS (Network Security Services) - This is a beast of a library. It should be updatable, to ensure the root certificate is correct.

2) Use Schannel - Microsoft Only - And very limited on Windows XP.

3) Make it the application responsibility to ensure the certificate public key matches the one expected from the Server. Via an "accept and install certificate", or hard coded in the application.

To be honest, I prefer option 3.

The current ClanLib TLS code needs refactoring to enable it to act as a server. Also how it handles the TCP connection is sub-optimal (since it blocks). This is out of my programming ability.

Judas
04-01-2013, 04:55 PM
As with all forms of security you always have to decide first:


what level security do you want
who are you trying to protect yourself against
what cost are you willing to pay

Security without context is meaningless and produces those pointless silly "you must have 10 letters, 1 capital letter and one special sign" requirements for websites requiring low security (like this forum site).

In the context of ClanLib TLS encryption I believe the level of security the library should be offering is not "can CIA hack this?" (they wouldn't bother - they'd just visit your server on site), or "does it withstand the most theoretical cracking techniques of measuring power changes depending on the encrypted message". Rather the goal should be to prevent script-kiddie traffic sniffing that telnet succumbed to, or enable low security apps to communicate over TLS. Anything above this is way outside the scope of ClanLib.

Certificate validation at this level of security is mostly about stopping man-in-the-middle attacks. Which boils down to mainly validating three things:


Is the DNS name used to contact the server listed in the certificate?
Is the certificate signature valid?
Was the certificate revoked?

Verifying those three things are somewhat problematic, since they are all based on the concept that you have some root CA certificates bundled with the application. The revoke check part requires contacting some server on the Internet (not sure of the technical details of that). In any case supporting this part would minimum require the app to tell the TLS classes in ClanLib which CA certificates should be used.

Personally I wouldn't bother to add the certificate validation part. Solve it by giving the certificate received from TLS to the application for validation. Then it is simply an official choice of ClanLibs TLS classes that the application accepts the responsibility of detecting of MITM attacks. Then if someone later has the needs helper functions could be added to perform the validation.



Also how it handles the TCP connection is sub-optimal (since it blocks). This is out of my programming ability.


Ideally the TLS classes should read bytes and write blocks - like the ZLib compress/decompress functions. Then a TCP transport is built on top of that, via feeding it data and writing the output data.

rombust
04-04-2013, 11:22 AM
For reference for other people reading this:

The TLS code (TLSClient) has moved into clanCore

The Network interface (TLSConnection) is in clanNetwork.