> On Apr 26, 2016, at 4:49 AM, Jeremy Harris <jgh@???> wrote:
>
> So much for encouraging people to actually use security.
One option is to generate a certificate on the fly at process startup if no
default certificate is configured. Sure, SNI might sometimes lead to a
different certificate, but if there's no exact match for SNI, the server
should still return a default certificate:
https://tools.ietf.org/html/rfc7672#section-8.1
If the server's TLSA records match the server's default certificate
chain, the server need not support SNI. In either case, the server
need not include the SNI extension in its TLS HELLO, as simply
returning a matching certificate chain is sufficient. Servers
MUST NOT enforce the use of SNI by clients, as the client may be
using unauthenticated opportunistic TLS and may not expect any
particular certificate from the server. If the client sends no SNI
extension or sends an SNI extension for an unsupported domain, the
server MUST simply send some fallback certificate chain of its
choice. The reason for not enforcing strict matching of the
requested SNI hostname is that DANE TLS clients are typically willing
to accept multiple server names but can only send one name in the SNI
extension. The server's fallback certificate may match a different
name acceptable to the client, e.g., the original next-hop domain.
With a default certificate in hand, STARTTLS never fails, and only
clients that perform authentication might complain that the certificate
did not match.
The default certificate can be generated in a shell script that starts
the server, or via C-code that generates a certificate in memory! (I
can provide that if you like).
Bottom-line, it is a good idea to enable TLS out of the box, but I think
more care is best to make sure that STARTTLS is not advertised when it
is sure to fail.
--
Viktor.
