tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] Forward TLS connection information from AWS ELB -> httpd -> Tomcat
Date Wed, 01 Oct 2014 17:18:41 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Frederik,

On 10/1/14 12:52 PM, Frederik Nosi wrote:
> Hi Christopher,
> 
> On 10/01/2014 06:05 PM, Christopher Schultz wrote:
>> -----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.
>> 
> 
> Maybe i didn't got your question right, what you're interested
> first, is letting know to tomcat that the client is using a secure
> connection? If so you can just pass a custom header from apache to
> tomcat, but this seems too easy :-)

No, I'm interested in convincing Apache httpd that the original
connection was encrypted. Basically, I want the equivalent of Tomcat's
secure="true" configuration option.

>>> 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.
> 
> I would get a tcpdump from the apache frontend, maybe you can get
> more info this way.

Yes, obviously I can do that. I was hoping that resorting to
packet-tracing would not be necessary.

>> 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.
> 
> Hmm, didn't knowed about this protocol before. From some quick
> googling and reading, seems interesting, as at your endpoint the
> connection comes from ELBs'IP not from the client's IP, this
> protocol adds the missing info, real client ip.
> 
> http://blog.haproxy.com/haproxy/proxy-protocol/
> 
> So using this seems you need to add another piece to you'r
> infrastructure.
> 
>> 
>>> 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
> 
> Indeed is better your way
> 
>> 
>> 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".
> 
> Then the easier solution seems using ELB for SSL termination and
> using the X-Forwarded-Proto header, passing from apache to tomcat

Yes. Just looking for a way to say "oh, the connection is also encrypted".

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJULDdxAAoJEBzwKT+lPKRYybAP/2Avx29/ESZP581ZXLFd3AkV
ptTls68M2I1SPlqdr9hFzKD1Uy8BcFS8wnZy6Joe+wBhLL7wGQ3ccukrr6bTHi6X
aUsUCe+L+Ce8l24mtEhWgqaTN4Ia0yBzUkWY9/xxt0Fhs2y6/LxOHOS9tWmD9VF4
+z3doNQ4JNvBpxiamBBxv5OGkF3m4S3Mof504sC5Xigsk2Kcon559nxOjQ2qLyMz
7HGLjHTJITCqfxMXHWAOAflTKzYr1aTl9rbEUhX5wgyIzAnJvSJTfmo1UedjsPFc
YcjdOyr5qOMuGfQj1Dr+W+0JKd6/pdmyu1gZ7/c2SnvNRzd4RoS2G7FEaq12vL77
B8BRkjMxfZ5suh+t5o+Cq9E5IdbdNRdEefaw3yilP9/O2jgV4EPrsxy7lzFVFkQQ
Tyx1Uty07eFnxL9GXqGdPVYKPqvdoMH8xYZIAIcv+b6cChyzkotB0haAtd9q/7h8
3J+ejCNzotM0Oiah0II3EP86S7Mumd8P/Yy7AdYwt6KOCyOCGUSrawCf+LJgPEGZ
sojggwHZvfQmd2m2ttlJMiXD/85ktpOv5lZCYhOsBzlf1KTCjr7Gsm/JuaLhdA5N
JPucWuDe3xjIem2TIV3e1/KwvCTJfS4hu3nh3QQE/AjbeVPdYMI2OW/qymVBDYDl
Z3Cz/TfcpCfeTg03eE2x
=aeQy
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message