There is a card for this (currently sitting in the backlog) - https://trello.com/c/Wc0RyLOy/423-r-d-encrypt-all-connections-by-default
I would like to provide supplemental information. The gear needs the ability to perform third party verification against the SSL variables. The customer has Apache modules to perform the verification. The verification must be cartridge specific for true multi-tenancy. A somewhat related Bugzilla is 1089703 (https://bugzilla.redhat.com/show_bug.cgi?id=1089703).
We've determined a work around which, for the time being, seems sufficient. Out of the box, the <VirtualHost *:443> on the node proxy looks like it is passing the client certificate. However, it doesn't seem to actually pass the cert unless the following three directives are added to the virtual host: SSLVerifyClient optional SSLVerifyDepth 10 SSLCACertificateFile "some file we specify" Next, I created a valve to deploy in the JBoss cartridge. The valve takes the client cert from the header "X-Forwarded-SSL-Client-Cert" and set the appropriate attribute in the request. Is it possible to get these three SSL directives added out of the box? I can imagine the "gotcha" is the "SSLCACertificateFile", since it would be deployment specific.
Ken, are you creating custom cartridges by any chance? If so, would using the OpenShift SNI proxy work for you? That should work with x509 certificates. You can read more about it here: https://github.com/openshift/origin-server/blob/master/plugins/frontend/haproxy-sni-proxy/README.haproxy-sni-proxy.md
We are trying to use the cartridges out of the box as much as possible. The addition of the three directives above allow us to pass the client cert to the current cartridges. I think that's the path we'll pursue for the moment. In any case, thanks for the information. I'll take a look at it.
(In reply to Ken Evensen from comment #4) > We've determined a work around which, for the time being, seems sufficient. > Out of the box, the <VirtualHost *:443> on the node proxy looks like it is > passing the client certificate. However, it doesn't seem to actually pass > the cert unless the following three directives are added to the virtual host: > > SSLVerifyClient optional > SSLVerifyDepth 10 > SSLCACertificateFile "some file we specify" > > Next, I created a valve to deploy in the JBoss cartridge. The valve takes > the client cert from the header "X-Forwarded-SSL-Client-Cert" and set the > appropriate attribute in the request. > > Is it possible to get these three SSL directives added out of the box? I > can imagine the "gotcha" is the "SSLCACertificateFile", since it would be > deployment specific. This might be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1038853 <<< there is already a valve shipped with EAP 6.2 that does this but it works off of the ssl_client_cert header. https://issues.jboss.org/browse/PRODMGT-822 was created to help address this.
(In reply to Eric Rich from comment #7) > (In reply to Ken Evensen from comment #4) > > We've determined a work around which, for the time being, seems sufficient. > > Out of the box, the <VirtualHost *:443> on the node proxy looks like it is > > passing the client certificate. However, it doesn't seem to actually pass > > the cert unless the following three directives are added to the virtual host: > > > > SSLVerifyClient optional > > SSLVerifyDepth 10 > > SSLCACertificateFile "some file we specify" > > > > Next, I created a valve to deploy in the JBoss cartridge. The valve takes > > the client cert from the header "X-Forwarded-SSL-Client-Cert" and set the > > appropriate attribute in the request. > > > > Is it possible to get these three SSL directives added out of the box? I > > can imagine the "gotcha" is the "SSLCACertificateFile", since it would be > > deployment specific. > > This might be a duplicate of > https://bugzilla.redhat.com/show_bug.cgi?id=1038853 <<< there is already a > valve shipped with EAP 6.2 that does this but it works off of the > ssl_client_cert header. > > https://issues.jboss.org/browse/PRODMGT-822 was created to help address this. If you are referring to the org.apache.catalina.valves.SSLValve, I discovered that as well. Unfortunately, as you pointed out, it looks for the cert in the ssl_client_cert header. This gave me enough inspiration to write a simple valve that looks in the header, specified by a parameter. If a parameter isn't specified, it looks in X-Forwaded-SSL-Client-Cert by default. It isn't overly complicated, but I'd be happy to feed this back to whoever is interested.
Your recommendation about the SSLValve compelled me to revisit what I had done. I realized that a minor modification to the SSLValve would enable us to use it without having to use a valve built from scratch. The modification I made was to "paramaterize" the header on which the client SSL cert is being presented. I sent the diff to your corporate e-mail.
I'm a little unclear as to the scope of this request at this point. If we're talking about having supported cartridges expose *extra* SSL connections via external (ssl_to_gear) ports, that just requires updating all the existing cartridges to do this. Tedious, but probably not too complicated, aside from needing to come up with an extra port per cartridge. Note that inter-gear communication would still be cleartext. However if we want to support *replacing* all the existing HTTP ports that are now used for inter-gear communication, that would imply the HAproxy LB gear has to support SSL in order to distribute requests to a scaled app. haproxy 1.4 does not support SSL connections. So we would need to ship HAproxy 1.5, and migrate existing haproxy cartridge instances over to it. That seems a lot more complicated. Can you clarify the scope?
(In reply to Luke Meyer from comment #14) > Note that inter-gear communication would still be cleartext. Could we not fix this by having request go to the SSL ports, exposed by the gear? > However if we want to support *replacing* all the existing HTTP ports that > are now used for inter-gear communication, that would imply the HAproxy LB > gear has to support SSL in order to distribute requests to a scaled app. > haproxy 1.4 does not support SSL connections. So we would need to ship > HAproxy 1.5, and migrate existing haproxy cartridge instances over to it. > That seems a lot more complicated. > Can you clarify the scope? The main goal of this is for SSL termination to happen at the gear (or service residing in the gear) so that a secure connection from the client (or gear to gear) can occur. This is needed for various use cases, one of them is x509 authentication at the gear.
(In reply to Eric Rich from comment #16) > > Note that inter-gear communication would still be cleartext. > > Could we not fix this by having request go to the SSL ports, exposed by the > gear? Not when the app HAproxy has to accept the request and proxy it, both in SSL, and HAproxy 1.4 doesn't support SSL. Inter-gear comms means scaled apps means HAproxy as a relay. > The main goal of this is for SSL termination to happen at the gear (or > service residing in the gear) so that a secure connection from the client > (or gear to gear) can occur. Makes perfect sense, just wanted to be clear that this is the goal and not something more easily done. > This is needed for various use cases, one of them is x509 authentication at > the gear. That particular use case would probably have to be handled at the node proxy anyway (or for an HA app, the routing layer) just like custom SSL certs. IMHO that goal is far easier to accomplish than "SSL everywhere".
(In reply to Luke Meyer from comment #17) > (In reply to Eric Rich from comment #16) > > > > Note that inter-gear communication would still be cleartext. > > > > Could we not fix this by having request go to the SSL ports, exposed by the > > gear? > > Not when the app HAproxy has to accept the request and proxy it, both in > SSL, and HAproxy 1.4 doesn't support SSL. Inter-gear comms means scaled apps > means HAproxy as a relay. Yes but due to the nature of haproxy it can do this as a layer 3/4 connection, and directly talk to the IP and port of the gear hosting the http or https connection. It would complicate the routing logic that we ship with haproxy quite a bit, but I believe it could be done. > > > The main goal of this is for SSL termination to happen at the gear (or > > service residing in the gear) so that a secure connection from the client > > (or gear to gear) can occur. > > Makes perfect sense, just wanted to be clear that this is the goal and not > something more easily done. > > > This is needed for various use cases, one of them is x509 authentication at > > the gear. > > That particular use case would probably have to be handled at the node proxy > anyway (or for an HA app, the routing layer) just like custom SSL certs. > > IMHO that goal is far easier to accomplish than "SSL everywhere".
(In reply to Eric Rich from comment #18) > > Not when the app HAproxy has to accept the request and proxy it, both in > > SSL, and HAproxy 1.4 doesn't support SSL. Inter-gear comms means scaled apps > > means HAproxy as a relay. > > Yes but due to the nature of haproxy it can do this as a layer 3/4 > connection, and directly talk to the IP and port of the gear hosting the > http or https connection. You would be giving up sticky sessions which are inserted at layer 7. Fine if your apps are non-scaled, stateless, or state is external, but that's an unexpected and probably unreasonable restriction to impose. And it would still be a substantial customization/change. And this wouldn't address the x509 use case unless the node proxy and routing layer could somehow also work at layer 4 (to avoid terminating SSL) and still use SNI to determine where to route the request. It's unclear to me if any open source LBs support this but I suspect not (and wouldn't want to assume the routing layer can either). So you end up having to terminate SSL and implement x509 auth at those layers anyway, not at the gear. In short, there are too many caveats to make this a useful solution IMHO. The only viable solution to all this is to keep SSL termination at the node / routing layer. You could then proxy new SSL connections back to the LB gears and to the framework gears once both are enabled to handle it, but that's really a separate issue from x509.
I just want to add that SNI proxying (layer 3/4 above) is certainly possible with haproxy 1.5 and probably other products ... other objections still apply.
Closing as wontfix for v2. Has been fixed in v3.