Re: Proposal for TLS config sanity check
On Tue, May 21, 2019 at 5:43 PM Mark Thomas wrote:
> On 21/05/2019 21:46, Christopher Schultz wrote:
> > All,
> >
> > Looking at the legacy-versus-modern TLS configuration (Connector vs
> > SSLHostConfig), it seems easy for an admin to create a configuration
> > that looks like this (paraphrasing):
> >
> >
> >>hostname="mysite.com"
> >SSLCertificateFile="keystore.p12" />
> >
> >
> > Where the expectation is that only TLSv1.2 will be enabled for virsual
> > host mysite.com when in fact only the virtual host named ("_default_")
> > will actually be limited to TLSv1.2 and other hosts will accept
> > connections using a TLS handshake with all default enabled protocols
> > (currently TLSv*).
> >
> > This may be surprising and there is no indication that there is
> > something "wrong" with the configuration. Only a TLS handshake probe
> > such as SSL Labs's testing tool will expose the oversight.
> >
> > I propose the following change to the and
> > initialization process:
> >
> > If the contains any TLS/SSL-related configuration AND at
> > least one element is configured, refuse to start the
> > connector (with an appropriate error message).
> >
> > This may cause a small number of configurations to fail to start. The
> > "workaround" is to re-evaluate one's configuration to (a) determine if
> > there was a misconfiguration where expectation and reality don't match
> > and (b) move all TLS/SSL-related configuration options from the
> > to each of the elements.
> >
> > Any objections?
>
Seems like a good idea to me.
>
> None.
>
> Given that the old style configuration is due to be removed in Tomcat
> 10, now is probably a good time to start doing this. I'd add logging a
> warning if the deprecated config style is used.
>
+1
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: Proposal for TLS config sanity check
On 21/05/2019 21:46, Christopher Schultz wrote:
> All,
>
> Looking at the legacy-versus-modern TLS configuration (Connector vs
> SSLHostConfig), it seems easy for an admin to create a configuration
> that looks like this (paraphrasing):
>
>
> hostname="mysite.com"
>SSLCertificateFile="keystore.p12" />
>
>
> Where the expectation is that only TLSv1.2 will be enabled for virsual
> host mysite.com when in fact only the virtual host named ("_default_")
> will actually be limited to TLSv1.2 and other hosts will accept
> connections using a TLS handshake with all default enabled protocols
> (currently TLSv*).
>
> This may be surprising and there is no indication that there is
> something "wrong" with the configuration. Only a TLS handshake probe
> such as SSL Labs's testing tool will expose the oversight.
>
> I propose the following change to the and
> initialization process:
>
> If the contains any TLS/SSL-related configuration AND at
> least one element is configured, refuse to start the
> connector (with an appropriate error message).
>
> This may cause a small number of configurations to fail to start. The
> "workaround" is to re-evaluate one's configuration to (a) determine if
> there was a misconfiguration where expectation and reality don't match
> and (b) move all TLS/SSL-related configuration options from the
> to each of the elements.
>
> Any objections?
None.
Given that the old style configuration is due to be removed in Tomcat
10, now is probably a good time to start doing this. I'd add logging a
warning if the deprecated config style is used.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Proposal for TLS config sanity check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Looking at the legacy-versus-modern TLS configuration (Connector vs
SSLHostConfig), it seems easy for an admin to create a configuration
that looks like this (paraphrasing):
Where the expectation is that only TLSv1.2 will be enabled for virsual
host mysite.com when in fact only the virtual host named ("_default_")
will actually be limited to TLSv1.2 and other hosts will accept
connections using a TLS handshake with all default enabled protocols
(currently TLSv*).
This may be surprising and there is no indication that there is
something "wrong" with the configuration. Only a TLS handshake probe
such as SSL Labs's testing tool will expose the oversight.
I propose the following change to the and
initialization process:
If the contains any TLS/SSL-related configuration AND at
least one element is configured, refuse to start the
connector (with an appropriate error message).
This may cause a small number of configurations to fail to start. The
"workaround" is to re-evaluate one's configuration to (a) determine if
there was a misconfiguration where expectation and reality don't match
and (b) move all TLS/SSL-related configuration options from the
to each of the elements.
Any objections?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzkY74ACgkQHPApP6U8
pFhC2hAAn4mw6c/TVXIfeornjhtE6nQY/2iAjp+fK5OxWpNW09LmDIK6Z/6rIfgS
9kUmfWWaslfUf04f1wmt0G599dQF1gyqHhy3XttgcUER21zpvDzeW9VVBKl7t1uh
zoaXii1ClMoY7Cg3iyuV+ULW0ETI6IyFVhWzecrwPbmWvKbw47s3VDXkimM66nJV
ZEcq47yOG3fogaadflU2GMMlvnAIJBcoW4qvQ7OHEzYliCpUFfP0ZmWPd9ufLP6G
U1otUw0yjaxsItae/PfKr4oiDPhu0pW1MdPhCBgBRS1UyByqn0fE4jf3xvng+OV9
WKxAVHObOUkI8GwNSTHqC2q8OJYrAiucGjYHM8/vPzA6RxpR0qWGO4mbD5NhD9HE
Nv178HEgrL1msuJPqCX7UYil5G8HHpTcXGnKe2jx9OJDoTv0BGmjDVOb+Xd8eIWB
il1DGTh73xe0mB0irLZxRYWME7u4pdMsbB2wkFpr8TGic6wYU0ZXXeVM+0xm/bDN
jy9FNEoQYkU2vu4eFyKLmm0/C1JbJfLRtUtPpoCk+QPt5v6TPjAONweCYy+LVi0c
IaBDmxixG/9l1sRNWr9+vYuR7pVnqAPQMggrlXQU6bBEJ3NU0F/CSWB+fOTTcGhe
BS0AP+gi8+Fsc0cw/yCPodO9VIbDuJw0IGsPxk12pwLm9c7g0LI=
=BuMa
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
