-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Frederik,
On 10/1/14 11:15 AM, Frederik Nosi wrote:
> Hi Christopher, On 10/01/2014 04:26 PM, Christopher Schultz wrote:
> All,
>
> I'm interested in using AWS ELB for SSL termination but allowing
> the client's TLS connection information to be forwarded all the
> way through the chain to Tomcat.
>
> The setup looks like this:
>
> ELB /\ / \ / \ w0 w1 / \ / \ t0 t1 t0 t1
>
> (t0 and t1 are repeated because otherwise the diagram would be
> even more difficult to read).
>
> w0 and w1 are running Apache httpd, t0 and t1 are running Tomcat.
> The client's connection is TLS terminated at ELB and whether the
> connections between ELB/wx/tx are encrypted should be immaterial.
> I'm using mod_jk from httpd -> Tomcat.
>
> ELB provides the following HTTP headers to wx: X-Forwarded-For
> (client's IP) X-Forwarded-Port 443 X-Forwarded-Proto https
>
> Unfortunately, it looks like I can't get things like the cipher
> default, etc. but I'm okay with that for the time being.
>
> I'm wondering two things:
>
> 1. How can I get Apache httpd to trust that the connection is
> encrypted? I want to be able to use "RequireSSL" for certain
> resources and have httpd trust that the connection coming from the
> ELB is in fact secure.
>
>> Maybe i'm missing something, but you can check that
>> X-Forwarded-Proto header contains https? Seems a bit risky, maybe
>> additionally adding another check that the incomming request
>> comes from ELB's IP(s)?
Yes, I can check this. I can also ensure that the port is only
accessible from the ELB. I'm less worried about this and more worried
about getting everything else working first. Protecting the connection
itself will not be a problem.
> 2. How can I use that connection information to tell mod_jk that
> things are to be trusted as well?
>
>> Just pass a custom header. BTW Are you encrypting the w <---> t
>> connections as well? BTW I recall a setup i've made times ago,
>> where the SSL termination was on the apache webservers, ex:
>
>> LB (tcp) <---- https ---> apache httpd (SSL Termination doing
>> client certificate verification) / mod_jk <--- AJP ---> Tomcat
>
>> I was able to send client's certificate information as headers
>> to tomcat. But not sure this is your situation.
I don't need to use client certificates, but being able to support
them would be nice.
AWS ELB seems to support TCP pass-through but you can't do it for port
443. If you want to use port 443, you can either choose "HTTPS/SSL" or
"TCP/SSL". If you choose "HTTPS/SSL" then you have to use either HTTP
or HTTPS as the back-end protocol. For some reason, choosing HTTPS
causes endless stalling when trying to make a connection.
Using TCP/SSL -> TCP/SSL (what I would call TCP pass-through) ought to
allow me to do SSL termination at the web server level, accept client
certificates, and have mod_ssk work without any modification at all. I
think in order to do this, I have to configure Apache httpd to accept
connections using the "proxy protocol", and I'm not sure how to do that.
> For #2, I might just be able to use SetEnv to set
> REMOTE_ADDR=X-Forwarded-For, but I'm not sure how to say "yes, this
> is encrypted". Should I set up a separate VirtualHost on a
> different (non-80) port that is configured only for ELB connections
> and then force SSL to "on" regardless of the actual incoming
> connections?
>> Maybe this can help:
>
>> RewriteEngine on RewriteCond %{HTTP:X-Forwarded-For} ^(.*)$ [NC]
>> RewriteRule ^(.*)$ - [env=JK_REMOTE_ADDR:%0]
>
>> This way you send to tomcat as REMOTE_ADDR the contents of the
>> X-Forwarded-For header
Why use mod_rewrite (slow) when you can use mod_setenvif (fast)?
SetEnvIf X-Forwarded-For "(.*)" JK_REMOTE_ADDR=$1
What I'm mainly looking for is a way to say "the incoming connection
(from ELB) is HTTP and I want to pretend that the connection is HTTPS".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULCZeAAoJEBzwKT+lPKRYHQcP/1tdeiy0lWAHcQ2vG4HrpACy
ni5Ac17Z5gSeqQyol66/NiOPBnRM9NaZqLg6wpIps+8SaZuKnHir2IgnWXOBo7lQ
81aJokPIivwO74ang6lnfJJR2vYCYLn7eONI6+qqSWlk+Mw2CoLbsGoPxVeeBBe7
AE+2QZnzj9NtuhlGiIKvlPQXmJBs/VgBiEq23wFsikLisY0eHMkwGcYnuPZ9KYil
qHxxmfntPgMH+uhCcxwGHrXlLJLCCGZCFv3xQHkCKC5Ndb9mnGBY1b0IcplPwOvQ
zbRVHdJcewE36hHECE5r2Z4a44ThKMLPEz1wZVCJm5ljEZiyuVq181ukkotBdvT8
y3/WuHwzZV8z6mdCNGBoB/Y4RdXfyfwaIKFZwlM3OhBcPVD+jki82dE/7tLZ3mlZ
AUj5pBGuoePVV8hnrukLi+DM4sJ6CZ6zLq0OKX3MzfF8n8/kG7vr20ntTi7mjTDs
Suk3lLr2L+Y7LBOzeepbThGK3CtCMm3OGZisuN90Pf9yrnuxDRJigpPUSeKdO0uQ
rJMx9gqRWiBl2jbWO6bsF4Aqy4wGVA+zyG9oTWMWDegU3uXHVAZdVb/R1YRZ18Qk
wH826ul3NMaUUGmWS6rpGpKpFm8V4UZ+qtz8eaMkBet3YOzYLBqJQ4xj5Co2K+g+
ZNKUGsHHHFYdVK9HyKcL
=PcDT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
