Re: [OT] Security of AJP
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Security of AJP
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:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Security of AJP
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org