Hi, > Therefore I took another route: The existing procedures keep their > current defaults, but there is a new set of object constructors that > uses only keyword arguments and configures things in a more secure > way by default.
That seems sensible to me, in particular as making existing APIs behave in backward incompatible ways tends to be ugly. Regarding specific improvements: > [procedure] (ssl-make-client-context* #!key > ((protocol <symbol>) 'tls) ((cipher-list <string|list>) "HIGH") > ((certificate-authorities <string>) #f) > ((certificate-authority-directory <string>) #f) > ((verify? <boolean>) #t)) > > Creates a new client context. Defaults to TLS protocol using only > ciphers marked as strong. Loads the certificate authorities from the > default directory unless other sources are specified and switches > server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. If you control both sides, you might want to use only ciphers with forward secrecy and without MAC-then-encrypt (to avoid padding oracles), for example, but if you make that the default for the egg, you'll find many servers out there that won't know how to talk to you. As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select "or higher" so code specifying that will automatically support newer TLS versions as they become available. As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) Verifying certificates by default is a very good idea indeed. Also, there are a few more things that are advisable to do for secure TLS, some of which (those that apply to the client side) are addressed by the patches that are currently blocked by andyjpb's fix, such as disabling TLS compression and requiring support for secure renegotiation from the server (though the latter may not be supported widely enough yet to make it the default, I'm not sure). On the server side, to make forward secrecy actually work, you have to set up callbacks that supply DH parameters and stuff, it's pretty ugly, but I may be able to supply code snippets if you are interested. Florian _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
