You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2018/02/27 22:18:49 UTC
Re: [OT] Security of AJP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Olaf,
On 2/27/18 4:33 PM, Olaf Kock wrote:
> On 27.02.2018 21:54, Mark A. Claassen wrote:
>> From what I have read, it seems that the AJP connector is not
>> secure, and is meant to be used in a protective environment.
>> There are lots of things that imply this, like no SSL settings
>> and such, but I cannot find it directly stated anywhere. I am
>> pretty confident in my read of this, but it is, of course,
>> difficult to say that "all options have been explored and it is
>> not possible".
>
> I would /not/ state that it's /not secure/. But I'm following your
> later argument: It's an "unencrypted connector", yes. In order to
> encrypt it, it needs to be run through an encrypted tunnel - and
> doing so is cumbersome, error prone and unrelated to the
> unencrypted nature of this connector.
We use stunnel in production to tunnel AJP from AWS-based web servers
and our back-end co-located app servers. We haven't had any problems
with that set up vis-a-vis connection failures or anything like that.
We haven't even had any issues with running out of file-handles for
stunnel.
So, yes, it's another component to configure and babysit, but I
wouldn't call it "cumbersome"... merely "more than you might expect"
when HTTPS through mod_proxy_http is an alternative.
> And yes, I rambled - couldn't resist. While I wouldn't object with
> your proposed change, I believe that the world wouldn't be notably
> better with it.
I disagree: I can imagine many administrators (or developers, who
often do make these decisions) overlooking the fact that AJP is a
plaintext protocol. It's definitely worth mentioning that fact, and
that it should only be used over trusted channels where anyone
observing the traffic is an acceptable risk.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqV2UkACgkQHPApP6U8
pFgLlw/9E6wzpmvNREE/FDL987ywmYtUVSCivIsMulGw9kA8VFgJ5fOTOOmoVThy
QoS9s5YUr7Xu5Gb1MmmoXmicCBj6Q4otN/FeCQA8z/EUJaW2XW4+UtHS9AVT9yRO
1bUzMuDnAtwRv10+JCepY2JUkkIKWKMhpdc725epX3EGwAxo6883YaHOKT1KN9Lh
Wu7FX3UK+xljWrIBmvBSaB6tu1xSjOwPW5Jshbr5JkrL7+WZpuww77f0n7ZEa8ij
IWFvPGyJYDdCTt2niBmcFanG7tRhBIHtnG52oOuu1qMACAfjwLboEpCbFXaea2p0
tlBXqVWLZnupRYan0/H5HO1djz/o4E65B3NTuMAZd+Kig9vrWEme97jC0ycN7MUI
gXpbMa2bNGvjsJjqDcorfFmmwgiQg+hlQbXUbutS6EPhYX+PRBVyphdlizhCaltw
acKq23RgT4KG0bugoUOFDPd0vvZzOIR3EAfM+L+lhVWqTTgyN6IlSFhAMFaygXUB
hMKwZVstZCLEp5NHusAPQv87rfd3zoU8UzROTpR6ujeSc99JadHgBw54hOxWKGMd
9ory3a4WWNMY8lf7jjXEG6RC2HyQzYWEJ9naj5z4O4BCXmG3QIeaPkYKDpCiviQA
l9X3n6q2X47Us8DhoSMXrZhX5Rc/8FbBHWQKr2PJbbRvC4KFmZQ=
=8x/9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Security of AJP
Posted by Olaf Kock <to...@olafkock.de>.
On 28.02.2018 16:01, Cheltenham, Chris wrote:
> In this case are you tunneling into tomcat via 8009 AJP connector?
"tunneling the (unencrypted) AJP connection between Apache httpd and
Tomcat, so that it's no longer transmitted in clear text." - that's how
I'd phrase it.
(and thank you Christopher, great input, this goes directly into my toolbox)
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Security of AJP
Posted by "Cheltenham, Chris" <cc...@philasd.org>.
In this case are you tunneling into tomcat via 8009 AJP connector?
===========================
Thank You;
Chris Cheltenham
Technology Services
The School District of Philadelphia
Work # 215-400-5025
Cell # 215-301-6571
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, February 28, 2018 9:37 AM
To: users@tomcat.apache.org
Subject: Re: [OT] Security of AJP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Olaf,
On 2/28/18 2:46 AM, Olaf Kock wrote:
> On 27.02.2018 23:18, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Olaf,
>>
>> On 2/27/18 4:33 PM, Olaf Kock wrote:
>>> On 27.02.2018 21:54, Mark A. Claassen wrote: I would /not/ state
>>> that it's /not secure/. But I'm following your later
>>> argument: It's an "unencrypted connector", yes. In order to encrypt
>>> it, it needs to be run through an encrypted tunnel - and doing so is
>>> cumbersome, error prone and unrelated to the unencrypted nature of
>>> this connector.
>> We use stunnel in production to tunnel AJP from AWS-based web servers
>> and our back-end co-located app servers. We haven't had any problems
>> with that set up vis-a-vis connection failures or anything like that.
>> We haven't even had any issues with running out of file-handles for
>> stunnel.
>>
>> So, yes, it's another component to configure and babysit, but I
>> wouldn't call it "cumbersome"... merely "more than you might expect"
>> when HTTPS through mod_proxy_http is an alternative.
>
> Nice. This is the first time that I hear that somebody actually does
> this. It's not surprising that it comes from this direction (e.g. you,
> somebody well known in this community).
I'd offer to do a talk on it at ApacheCon, but it would be a short talk. The
following config files have 12 lines of effective configuration, 6 of which
come out of the box in the basic configuration (everything at the top, until
you get to the "basic TLS stuff" comment):
=== CUT ===
# stunnel configuration file (web server) # boilerplate stuff:
pid=/stunnel.pid
chroot=/var/lib/stunne4l
setuid=stunnel
setgid=stunnel
socket=l:TCL_NODELAY=1
socket=r:TCP_NODELAY=1
# Basic TLS stuff
sslVersion = TLSv1.2
fips=no
# we are a client
client=yes
# Connection information
[ajp13]
accept=localhost:8009
connect=backend.example.com:8010
=== CUT ===
# stunnel configuration file (app server) # boilerplate stuff:
cert=/etc/stunnel/stunnel.pem
pid=/stunnel.pid
chroot=/var/lib/stunne4l
setuid=stunnel
setgid=stunnel
socket=l:TCL_NODELAY=1
socket=r:TCP_NODELAY=1
# Basic TLS stuff
options=NO_SSLv2
options=NO_SSLv3
[ajp13]
accept=8010
connect=localhost:8009
=== CUT ===
stunnel runs on both sides of the connection.
The connection looks like this:
httpd [mod_jk] - AJP13 -> localhost:8009 [stunnel] - TLS ->
backend.example.com:8010 [stunnel] - AJP13 -> localhost:8009
The "TLS" part of the connection goes across the network to the backend
host. The first "localhost" refers to the web server talking to itself over
the loopback connection, and the second "localhost"
refers to the app server talking to itself over the loopback connection.
We aren't doing anything with mutual TLS authentication (client certs)
because we are using IP-based whitelisting. I suppose we could tighten-up
security a bit by using client certs, but then we'd have more key material
out on our web servers and, really, how secure is that ?
I assume someone will talk about proxying at ApacheCon. I'll ask them to
stick in a slide about using stunnel since it's fairly short. Just a picture
and a sample configuration.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqWvpMACgkQHPApP6U8
pFic2g//RW73Z/NyDIDms4KDASzNYxA+zqwYOO2Sb4pv0I/i776azJzMFcRKJkyO
CygbvVEgQosQkrWw8suzpeg67AmcviwE9U21TvcDPZAJGOHE/KVtADnxKzy6QFit
B280c39HDqGGz23T2FxkSmErZ8w29ZqdH3YoGFG+wj46qpJO6oWWq342EXYwLsGo
9HhE6+J1LrRotPZ8eYvGoqbHIWA6VQP+eJ1bIbUGci/tv9ShF6FyoRZl2tBjbXHb
vIBxL1X/z+yEy4ue2L3W4DglgSzRhlOKaPOwV/vKWq5fUgipoQD22K8G64Mj5X5H
2/PvmvENqcM0VhIn1WSSbsKYol+v2xKk4g3IRH5ifDnjZaJkWxR5buxn5uCcgMsh
Ojq4myGFjqp7KHllUWCo+VphE/JrNRoxEYQQnnylyt6Hd2l8nJsO1KK6Ce5beexn
YnKBCJ3Fl45TgVlJloabD5NFpyzRoS7LYB9BKHBqoFeSVoUEsO2Yaog3liKqVYp2
7WfOovoPrVdH6UBRCNkVygJacJwtNul502lV/EdqwyX17qoi0G8wRd5i1Vwe61zV
XZisJsYuk9kCRC08mi1B4Ja5Vt3D1zq9KrIvSLdLeR//Af8lul+kbOvg2ZvWXWUT
ck54nJo70iNNa3gwZ5IfmbNdnYnm3fACVXxeWXo5rNIxrX6mROU=
=0/CI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Security of AJP
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Olaf,
On 2/28/18 2:46 AM, Olaf Kock wrote:
> On 27.02.2018 23:18, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Olaf,
>>
>> On 2/27/18 4:33 PM, Olaf Kock wrote:
>>> On 27.02.2018 21:54, Mark A. Claassen wrote: I would /not/
>>> state that it's /not secure/. But I'm following your later
>>> argument: It's an "unencrypted connector", yes. In order to
>>> encrypt it, it needs to be run through an encrypted tunnel -
>>> and doing so is cumbersome, error prone and unrelated to the
>>> unencrypted nature of this connector.
>> We use stunnel in production to tunnel AJP from AWS-based web
>> servers and our back-end co-located app servers. We haven't had
>> any problems with that set up vis-a-vis connection failures or
>> anything like that. We haven't even had any issues with running
>> out of file-handles for stunnel.
>>
>> So, yes, it's another component to configure and babysit, but I
>> wouldn't call it "cumbersome"... merely "more than you might
>> expect" when HTTPS through mod_proxy_http is an alternative.
>
> Nice. This is the first time that I hear that somebody actually
> does this. It's not surprising that it comes from this direction
> (e.g. you, somebody well known in this community).
I'd offer to do a talk on it at ApacheCon, but it would be a short
talk. The following config files have 12 lines of effective
configuration, 6 of which come out of the box in the basic
configuration (everything at the top, until you get to the "basic TLS
stuff" comment):
=== CUT ===
# stunnel configuration file (web server)
# boilerplate stuff:
pid=/stunnel.pid
chroot=/var/lib/stunne4l
setuid=stunnel
setgid=stunnel
socket=l:TCL_NODELAY=1
socket=r:TCP_NODELAY=1
# Basic TLS stuff
sslVersion = TLSv1.2
fips=no
# we are a client
client=yes
# Connection information
[ajp13]
accept=localhost:8009
connect=backend.example.com:8010
=== CUT ===
# stunnel configuration file (app server)
# boilerplate stuff:
cert=/etc/stunnel/stunnel.pem
pid=/stunnel.pid
chroot=/var/lib/stunne4l
setuid=stunnel
setgid=stunnel
socket=l:TCL_NODELAY=1
socket=r:TCP_NODELAY=1
# Basic TLS stuff
options=NO_SSLv2
options=NO_SSLv3
[ajp13]
accept=8010
connect=localhost:8009
=== CUT ===
stunnel runs on both sides of the connection.
The connection looks like this:
httpd [mod_jk] - AJP13 -> localhost:8009 [stunnel] - TLS ->
backend.example.com:8010 [stunnel] - AJP13 -> localhost:8009
The "TLS" part of the connection goes across the network to the
backend host. The first "localhost" refers to the web server talking
to itself over the loopback connection, and the second "localhost"
refers to the app server talking to itself over the loopback connection.
We aren't doing anything with mutual TLS authentication (client certs)
because we are using IP-based whitelisting. I suppose we could
tighten-up security a bit by using client certs, but then we'd have
more key material out on our web servers and, really, how secure is that
?
I assume someone will talk about proxying at ApacheCon. I'll ask them
to stick in a slide about using stunnel since it's fairly short. Just
a picture and a sample configuration.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqWvpMACgkQHPApP6U8
pFic2g//RW73Z/NyDIDms4KDASzNYxA+zqwYOO2Sb4pv0I/i776azJzMFcRKJkyO
CygbvVEgQosQkrWw8suzpeg67AmcviwE9U21TvcDPZAJGOHE/KVtADnxKzy6QFit
B280c39HDqGGz23T2FxkSmErZ8w29ZqdH3YoGFG+wj46qpJO6oWWq342EXYwLsGo
9HhE6+J1LrRotPZ8eYvGoqbHIWA6VQP+eJ1bIbUGci/tv9ShF6FyoRZl2tBjbXHb
vIBxL1X/z+yEy4ue2L3W4DglgSzRhlOKaPOwV/vKWq5fUgipoQD22K8G64Mj5X5H
2/PvmvENqcM0VhIn1WSSbsKYol+v2xKk4g3IRH5ifDnjZaJkWxR5buxn5uCcgMsh
Ojq4myGFjqp7KHllUWCo+VphE/JrNRoxEYQQnnylyt6Hd2l8nJsO1KK6Ce5beexn
YnKBCJ3Fl45TgVlJloabD5NFpyzRoS7LYB9BKHBqoFeSVoUEsO2Yaog3liKqVYp2
7WfOovoPrVdH6UBRCNkVygJacJwtNul502lV/EdqwyX17qoi0G8wRd5i1Vwe61zV
XZisJsYuk9kCRC08mi1B4Ja5Vt3D1zq9KrIvSLdLeR//Af8lul+kbOvg2ZvWXWUT
ck54nJo70iNNa3gwZ5IfmbNdnYnm3fACVXxeWXo5rNIxrX6mROU=
=0/CI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Security of AJP
Posted by Olaf Kock <to...@olafkock.de>.
Hi Christopher,
On 27.02.2018 23:18, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Olaf,
>
> On 2/27/18 4:33 PM, Olaf Kock wrote:
>> On 27.02.2018 21:54, Mark A. Claassen wrote:
>> I would /not/ state that it's /not secure/. But I'm following your
>> later argument: It's an "unencrypted connector", yes. In order to
>> encrypt it, it needs to be run through an encrypted tunnel - and
>> doing so is cumbersome, error prone and unrelated to the
>> unencrypted nature of this connector.
> We use stunnel in production to tunnel AJP from AWS-based web servers
> and our back-end co-located app servers. We haven't had any problems
> with that set up vis-a-vis connection failures or anything like that.
> We haven't even had any issues with running out of file-handles for
> stunnel.
>
> So, yes, it's another component to configure and babysit, but I
> wouldn't call it "cumbersome"... merely "more than you might expect"
> when HTTPS through mod_proxy_http is an alternative.
Nice. This is the first time that I hear that somebody actually does
this. It's not surprising that it comes from this direction (e.g. you,
somebody well known in this community).
>> And yes, I rambled - couldn't resist. While I wouldn't object with
>> your proposed change, I believe that the world wouldn't be notably
>> better with it.
> I disagree: I can imagine many administrators (or developers, who
> often do make these decisions) overlooking the fact that AJP is a
> plaintext protocol. It's definitely worth mentioning that fact, and
> that it should only be used over trusted channels where anyone
> observing the traffic is an acceptable risk.
As I said: I won't object to the change. And given my statement about
taking advice from the first hit on stackoverflow, I guess I'll have to
take back my conclusion: The world would be slightly better. I've leaned
towards my default to rather /not/ document what a feature can /not/ do,
because this kind of documentation makes docs hard to read.
Thinking about this situation again, here's a case with a benefit. Not
only would I not object - I'll now fully support it. (well, not that
this has any weight, but it feels good to have a new insight. Thank you
for that)
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org