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
