Bug 61984 - mod_ssl has SSLProxyVerify set to none by default
Summary: mod_ssl has SSLProxyVerify set to none by default
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-10 00:16 UTC by Dan Oliver
Modified: 2018-01-10 21:30 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Oliver 2018-01-10 00:16:40 UTC
mod_ssl has SSLProxyVerify set to none by default.

SSL offers no real security without verification of the cert, so this should be turned on by default.  Those who may not read into the entire configuration could incorrectly believe that by using SSL it is doing the sensible default thing here, checking the certificate.  This could lead to configurations that are susceptible to MiTM attacks via self signed certs.
Comment 1 Yann Ylavic 2018-01-10 12:58:10 UTC
The point is that SSLProxyVerify != none pairs with SSLProxyCACertificate{Path,File}, and there is really no default for the latter(s) obviously...
Comment 2 Dan Oliver 2018-01-10 15:37:24 UTC
Yes.  A valid setup for SSL would require the signers file to be specified.  Here is a question, would it be better to have someone have to know that they need to supply a valid signer or explicitly turn off certificate validation to get a working setup or would it be better for someone to be expecting the certificate to be checked by default and ending up with an insecure setup?  I guess one factor in that might be how likely it should be to expect the certificate to be checked and I would suggest that SSL is totally useless without that check, so the idea that a check would not be done by default is not intuitive.  I think it would be very telling to look at how virtually any other software handles this.
Comment 3 Yann Ylavic 2018-01-10 17:43:03 UTC
I don't know, when a proxy is configured that's already the MITM, right?
So you need to persuade your clients that you are the one "man" already.

In a reverse proxy scenario you'd use the domain's certs (which you can't fake, browsers watch!) for inbound connections, and either be confident enough about your internal network (with no SSL at all, or no authenticated SSL for eavesdropping prevention only), or that network is not trusted and you probably should know how to enforce authentication with the backend (one or two way) as a typical domain admin.

In a forward proxy scenario, it's kind of the same thing besides you also need now to ensure the trust your clients put on the proxy (to reach the right origin server), so you have to face the burden of maintaining the "CAs/keystore of the internet" locally like browers do, not easy but the price for trust here.

In any case I think that for running a proxy one needs to have a look at its documentation (for the least), so I would go for a note/warning about non-authenticated TLS on the mod_ssl page, if none exists already.
Comment 4 Dan Oliver 2018-01-10 17:57:55 UTC
If certs are not being authenticated then SSL is not being setup properly.  I'm not saying that someone shouldn't be able to do something incredibly dangerous, but it shouldn't be the default.

In the case of someone setting up an rproxy on an untrusted network, if someone incorrectly assumes that perhaps their CACertificateFile they have already provided for their front end SSL configuration is also being used on the back end (not understanding there is a separate SSLProxyCACertificateWhatever) and they perform their initial setup with certs that are signed by a signer from their front end, they may not realize that no verification of the certificate is being done at all.  That is to say someone might understand how to theoretically set up an SSL connection on an untrusted network, but the configuration directives and defaults are not intuitive and without a careful read of the documentation could be deployed unsecurely even by an experienced individual.

The documentation should definitely be more clear, but being that the default should be updated.  I have NEVER seen another program that when set up to use SSL does not attempt to properly verify the certificate by default.
Comment 5 Yann Ylavic 2018-01-10 21:30:58 UTC
Startup failure is certainly not the norm, nginx and ATS don't do that for instance (and default to verify none too), haproxy seems to require a ca-file by default though (in any event, none takes the frontend's configuration as the backend's one, AFAICT).

I don't think we can change this in any httpd released versions without breaking existing configurations for reverse proxies (e.g. in trusted environments, the most common ones IMHO), we can't make httpd startup fail all of a sudden because "SSLProxyVery none" wasn't specified.

The SSL* vs SSLProxy* cases may not be ovious, but we have to differentiate between the frontend vs backend SSL configurations anyway, and somehow both SSLEngine and SSLProxyEngine had better be used for your configuration to work in the first place, there is a reason for that, nothing implicit here.

I'm not saying understanding/configuring SSL is easy, nor that it shouldn't be improved, but I don't think we should error by default, even in future versions.
SSL isn't the default for mod_proxy, one has to set it up explicitely, and that must be done above "SSLProxyEngine on" for sensible cases (like untrusted networks), no one should ignore that.

So still a documentation issue for me, let's see what others think for the next major version.