add optional SSL support

[fsagbuya]

Description

Add optional SSL/TLS support with mutual authentication. SSL is enabled when certificate files are provided.

• Add SSL context creation in AsyncioServer requiring both server and client certificates
• Update Client, AsyncioClient, and BestEffortClient classes to support mutual SSL authentication
• Modify simple_server_loop to handle certificate verification
• Add SSL parameter support to sipyco_rpctool (--cert, --key, --cafile)
• Add documentation for SSL setup and usage including certificate generation

Related issue:

m-labs/artiq#2577

[sbourdeauducq]

Needs documentation (docstring update).

[sbourdeauducq]

Many things missing, e.g.

• support in rpctool
• support in other sipyco protocols: sync_struct, logging, broadcast
• documentation about how to generate certificates

[sbourdeauducq]

You could do the protocols one by one if you prefer, and then we merge those PRs to a separate branch first.

[sbourdeauducq]

This doesn't authenticate the client, does it?
The main point of having SSL is preventing unwanted users from connecting to sipyco servers.

[sbourdeauducq]

I think you can add a client certificate (with different SSL API calls), or just a password.

[architeuthidae]

All this limits the server to connecting to only one client, no? Is that a limitation we're accepting? If so, it should probably be documented.

[sbourdeauducq]

Yeah I'm not convinced of this certificate setup with IP addresses in them. We do want to allow several clients on one server, but I suppose they could share the same client certificate (if this IP address business doesn't get in the way).

[architeuthidae]

We do want to allow several clients on one server, but I suppose they could share the same client certificate (if this IP address business doesn't get in the way).

If they don't share an IP address and check_hostname is on I assume it'd cause problems. I figure theoretically the cleanest solution is to sign further client certificates CA-style but sharing the certificate (and disabling check_hostname) may be more user-friendly. At that point though it might also be friendliest to just disable the certificate check entirely and just use a password on top of basic TLS, that way nobody has to worry too much about the PKI stuff.

[sbourdeauducq]

At that point though it might also be friendliest to just disable the certificate check entirely and just use a password on top of basic TLS

This still needs some certificates, no?

[architeuthidae]

This still needs some certificates, no?

Yes, but it no longer matters what certificate, or who they're signed by. At that point it's just a way to trade public keys.

[sbourdeauducq]

Yes, but it no longer matters what certificate

Then what prevents a MITM attack that intercepts the password?

[architeuthidae]

Then what prevents a MITM attack that intercepts the password?

Hmm, nothing. Nevermind.

[sbourdeauducq]

Sounds like we should try to go for shared client certificates (created without IP address/hostname fields) and check_hostname=False then?

[fsagbuya]

Sounds like we should try to go for shared client certificates (created without IP address/hostname fields) and check_hostname=False then?

Based on the previous discussion, this is the simplest solution. Otherwise, a full private CA setup is an option, but it wouldn't be user-friendly.

[sbourdeauducq]

Add asyncio_tools that imports tools with a DeprecationWarning for backward compatibility.