3 ms·

Not using dhparam? Dont like ECDH? I wrote a similar amateur script years ago which has required updates from time to time to reflect new developments in the

Not using dhparam? Dont like ECDH? I wrote a similar amateur script years ago which has required updates from time to time to reflect new developments in the ongoing SSL saga. This was started before anyone cared about SNI. If the use case for the CA is a home network, I prefer using a local SSL-enabled proxy for connecting to both remote and local SSL-enabled endpoints. This lets me specify a short list of acceptable ciphers. It also permits me to use legacy, non SNI-enabled SSL/TLS clients. The remote and local hosts are "backends" that go in the proxy config file. I control DNS via local root or use HOSTS to redirect to the proxy. If I was running multiple local SSL enabled devices/servers from the same local IP on a home network, then I believe I could just put these in the config file as backends listening on high, unprivileged ports. I do not believe I would need SNI because I could filter requests based on domain name and/or the filepath in the url. The ultimate solution IMO would be an sslwrap type utility that has been revised to use more modern encryption, i.e. NaCl. Any application could then use NaCl instead of SSL/TLS, without having to modify the application. The NaCl author has menitoned several times that he has written such a utility and even said he will release it at some point. IMO, that would be a big step in freeing us from the ills of SSL/TLS and the 3rd party CA system. Users would get easy-to-use, high quality, high speed cryptography without having to learn all of the SSL/TLS complexity, not to mention having to keep up with incessant bugs and security updates.

icebraining 9y ago
I do not believe I would need SNI because I could filter requests based on domain name and/or the filepath in the url. The point of SNI is to send the domain name as part of the TLS handshake, because the URL is only sent after the secure connection is established (after the cert is sent).
feelin_googley 9y ago
The point of SNI, i.e. the reason for its existence, is to allow more than one SSL-enabled website to use the same shared IP address. Prior to SNI each SSL-enabled website required its own dedicated IP address. On a home network, is shortage of RFC1918 IP addresses really a problem?
tptacek 9y ago
If you shed all legacy compatibility and narrow your configuration down to modern AEAD ciphersuites and an ECDH handshake, you can get TLS to a point asymptotically as secure as the best secure transport you'd achieve with NaCL and no other crypto primitives. Which leaves you to wonder why you'd bother doing the NaCL thing at all --- which is probably why not many people use custom secure transports. Most (not all) of what's gone wrong with TLS has gone wrong in things that had already been outmoded for a very long time, and long since replaced with better constructions in later versions of the protocol.
- feelin_googley 9y ago
  One of the things that perplexes me as a naive user about TLS is the ridiculous number of cipher choices. How do you explain it? Some people still need them? Impossible/impractical to cut TLS down to size? People who comment intelligently about crypto seem to agree that complexity is the enemy of security, but does TLS even try to reduce complexity? There is so much accumulated cruft to SSL/TLS and the implemented x509 certificate scheme that to me, as a noob who knows nothing about crypto i.e. the average user, the easier path is to scrap all that ("shed all legacy" junk) and focus on learning a few things that are both flexible and known to be useful. I believe NaCl fits this role. I have some basic UNIX-like utilities built with NaCl, one for each function (crypto_box, crypto_secretbox, etc.). Minimal non-djb code. In the interests of experimentation and learning, I prefer using small, separate utilities versus applications that do multiple jobs. I would be interested in an "expert" opinion on my experiments with these utilities but crypto is such a devisive topic. Though they may be initiated as sensible, honest questions, online discussions quickly turn toward dogma supporting status quo, mindless memes, subtle insults and are sometimes derailed into the realm of absurdity. I would post an example of the usage for comment, but I am not interested in being chastised by the HN peanut gallery. It is just intellectual experimentation, nothing more. IMO, as a general principle not limited to crypto, there is nothing wrong with "custom" anything if it has passed the same QA tests as the "mass-produced" version. Sometimes in fact custom is higher quality than mass-produced. Popularity does not always signify higher quality. Perhaps nowhere is this more evident than in the world of software. IMO, a "naclwrap" program would be very useful, even in a "TLS world". Like stunnel but for nacl. Whether "everyone" would use it is an interesting question but ultimately not something I care about.

icebraining 9y ago

I do not believe I would need SNI because I could filter requests based on domain name and/or the filepath in the url. The point of SNI is to send the domain name as part of the TLS handshake, because the URL is only sent after the secure connection is established (after the cert is sent).

feelin_googley 9y ago

The point of SNI, i.e. the reason for its existence, is to allow more than one SSL-enabled website to use the same shared IP address. Prior to SNI each SSL-enabled website required its own dedicated IP address. On a home network, is shortage of RFC1918 IP addresses really a problem?

tptacek 9y ago

If you shed all legacy compatibility and narrow your configuration down to modern AEAD ciphersuites and an ECDH handshake, you can get TLS to a point asymptotically as secure as the best secure transport you'd achieve with NaCL and no other crypto primitives. Which leaves you to wonder why you'd bother doing the NaCL thing at all --- which is probably why not many people use custom secure transports. Most (not all) of what's gone wrong with TLS has gone wrong in things that had already been outmoded for a very long time, and long since replaced with better constructions in later versions of the protocol.

feelin_googley 9y ago
One of the things that perplexes me as a naive user about TLS is the ridiculous number of cipher choices. How do you explain it? Some people still need them? Impossible/impractical to cut TLS down to size? People who comment intelligently about crypto seem to agree that complexity is the enemy of security, but does TLS even try to reduce complexity? There is so much accumulated cruft to SSL/TLS and the implemented x509 certificate scheme that to me, as a noob who knows nothing about crypto i.e. the average user, the easier path is to scrap all that ("shed all legacy" junk) and focus on learning a few things that are both flexible and known to be useful. I believe NaCl fits this role. I have some basic UNIX-like utilities built with NaCl, one for each function (crypto_box, crypto_secretbox, etc.). Minimal non-djb code. In the interests of experimentation and learning, I prefer using small, separate utilities versus applications that do multiple jobs. I would be interested in an "expert" opinion on my experiments with these utilities but crypto is such a devisive topic. Though they may be initiated as sensible, honest questions, online discussions quickly turn toward dogma supporting status quo, mindless memes, subtle insults and are sometimes derailed into the realm of absurdity. I would post an example of the usage for comment, but I am not interested in being chastised by the HN peanut gallery. It is just intellectual experimentation, nothing more. IMO, as a general principle not limited to crypto, there is nothing wrong with "custom" anything if it has passed the same QA tests as the "mass-produced" version. Sometimes in fact custom is higher quality than mass-produced. Popularity does not always signify higher quality. Perhaps nowhere is this more evident than in the world of software. IMO, a "naclwrap" program would be very useful, even in a "TLS world". Like stunnel but for nacl. Whether "everyone" would use it is an interesting question but ultimately not something I care about.