Re: Breakthrough, Re: Let's Encrypt with Tomcat?
On 1/7/20 4:54 PM, Christopher Schultz wrote: I have further confused you, because TCP packets+connections also have state, and I misspoke. Think nothing of it: at my age, I'm easily confused. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 7:22 PM, James H. H. Lampert wrote: > On 1/7/20 4:17 PM, Christopher Schultz wrote: >> iptables doesn't work on pipes, it works on packets. So you have >> to redirect both incoming AND outgoing packets. That's why you >> have the "output redirect" as well as the (more obvious) "input >> redirect". > > Well, that just leaves me more puzzled than ever: why would our > webapp (and Manager, for that matter) "work just fine" even though > there's no sign of an output redirect in the iptables-save output > (which I posted in its entirety)? I have further confused you, because TCP packets+connections also have state, and I misspoke. For UDP, you'd need the output redirect. The TCP stack knows where the packets from a particular connection came from, so responses along the same connection will go back the way they came (this is NAT). I'm not sure under what circumstances you need an OUTPUT redirect. I seem to remember in my testing that I did indeed require the OUTPUT redirect for things to work properly, but I may be making that up. The slides mention that you "may need" those, and so I went ahead and put the commands into the slides to show how to do it, if necessary. Actually, it's not INPUT and OUTPUT, it's PREROUTING and POSTROUTING. But those are basically the same concept for NAT as INPUT/OUTPUT are for the "filter" tables. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VKC8ACgkQHPApP6U8 pFjqSRAAtKLif+WBswtmW8jOswhHn2SNRX2jUPm/RYOf7YqEFMYgeunA6GqewcT0 E2AVcBangWNGLuMWaaDhmFb5S4KcgW2c5HlbafBVtdggESkfjzozJnBw+sg6ShbZ SxRQ4Lty/WwczAwduHkOaG7pFIeQlTKLSA1wL5zCJ02hQllYa1CYGIxMRAbwqu/m 1oC0jgiJs1zGXQN7XlgZdTD6uyHuUEhSLzh0it8+QtWEoLtki+LcvRy+Bmv+nEtw ssqHpCX+TD4PnhcLpgFqWzy3DrUJYPUdV6dExnBujrFe2tzBAYtZfDy+Gshb6efo LtGdLwaHgd6BLA71wEUEGMr85o9Opeuu1l3niENP/WaOuELidre3+umAVWr5Ypdq zSGhO6clt6V9JCpXqM1EWh18hjDomKLb6Q1V9hpeTbBodmr8yFGo6D9pv9lddRyD ArXxmqvL3aUSWXb80zrsUuPYXTO+SIbIXJRSJGPVRWM7eCrO8o1VpeTcD1bsXnPz 3l32YDEd6hbWjwLMWKzWu4oIuoZlHiCgsx4Tm2T0KtdBRn2/kStTLIoXOF5s129Y ewZ0ygViiPqnTL1QD1jwnKG7EuAplx9ppKXCRM1MSbbB/+VSjdwDFvQCAnVykLhg IB0AniJsaYP6BnPIGHcihPU3mj7Qp9uGcm/3QeAIwX0ULf1iEKs= =tP73 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
On 1/7/20 4:17 PM, Christopher Schultz wrote: iptables doesn't work on pipes, it works on packets. So you have to redirect both incoming AND outgoing packets. That's why you have the "output redirect" as well as the (more obvious) "input redirect". Well, that just leaves me more puzzled than ever: why would our webapp (and Manager, for that matter) "work just fine" even though there's no sign of an output redirect in the iptables-save output (which I posted in its entirety)? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 12:28 PM, James H. H. Lampert wrote: > On 1/7/20 7:32 AM, Christopher Schultz wrote: >> Hah, sorry about that. Nobody thought of specifying that only >> root can view the iptables stuff. :) > > Not your fault, nor that of anybody else here; I blame the author > of iptables and iptables-save: it should either (a) allow *anybody* > to *see* the information, or (b) *tell* the user that he/she is > not authorized to see it. > > While I occasionally use "quiet failure" myself, when writing code > to protect database fields from unauthorized modification, I > generally do so only when it actually makes sense, and the user can > actually *see* that his or her attempt to change the value(s) was > quietly ignored. > > *** > > But I'm still puzzled about the "output redirect" specified in the > presentation, but absent from this installation (and yet it still > works just fine). iptables doesn't work on pipes, it works on packets. So you have to redirect both incoming AND outgoing packets. That's why you have the "output redirect" as well as the (more obvious) "input redirect". > Does the "proxyPort" clause on the connector have something to do > with it "working just fine" without the "output redirect"? The proxyPort is just a configuration option which overrides the port that will be used when Tomcat is building URLs that point back to itself (e.g. Location: for redirects). If Tomcat is listening on port 8443, then, obviously, port 8443 should be used. But if there is a reverse-proxy in the way (or some other hand-wavy magic like iptables), then you want to use the port that the CLIENT needs to use to get back to you, regardless of the actual port being bound to by Tomcat. It's just like setting the virtual host hostname: you can't just take-over "microsoft.com" by setting your 's hostname to "microsoft.com". But if you don't do that, your users might be sent to "node-1-6-2-4-6-32-34.binhost.net" which isn't quite what you want. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VH60ACgkQHPApP6U8 pFiW/g//VnCbgnHs/fbsxKANfdIwNGSZP37SEkfLMOzQxBK9eC6nb6LQeWHw5FQd 8yVFVP1LnbvM0ey+UDhWME7Chbm9iyLfpMO09BqAuzcJWopODk9JYQOn0YFJsiVh kcKeoUGLV1nw4I3qPdh0fjVRV6GDwSpt9XXZvwOZdIbqBUrS+rGuobBDJU5SaA8y SSVzTYKqoHryJAt7yNiPkulrqpS7rgmiLbm/RvDfF5VFnaYMfh3/Mz7kmBhcvDDC lkG2+Zs29g/mQ3YyCoKCKLfs0m7bS3WHlxv9qwsZkJzx0Rql2LJ1PSgPnO9vh4VH LecAk9/6rQGySVuDY4f8r265Gm/jDAn5z+WWT8mv6FsbZZckYbm4f+8DYhxzWjh0 jYJNJf0dOorjjUY7hIQKw9k+QQgBKdufKtfHpDK5u1MIYsC8pdrzyjN9LFl566ad ESEtlXjnFCzCr9wobi7YJAJLXc9rFsd/IoN988Oui69RIroqZWL6Jjxetj4fDr+8 RiJiTiSl8yWXZuSpkHrQuIrD4eLSpdoOWkrNJOOzDExuJbTpPpFABjapqSrWDEV/ BP0+xAKzeH4RMHLyUciVzw4czRe8DB/0mOBIxSv5z2LXKlef07McFzg8ACOsMCS2 oCG7vXqh7iZbNdB+AKhFs0+TIxJNcBe8bT75t0LF7xgcD0nyXf4= =67mG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
On 1/7/20 7:32 AM, Christopher Schultz wrote: Hah, sorry about that. Nobody thought of specifying that only root can view the iptables stuff. :) Not your fault, nor that of anybody else here; I blame the author of iptables and iptables-save: it should either (a) allow *anybody* to *see* the information, or (b) *tell* the user that he/she is not authorized to see it. While I occasionally use "quiet failure" myself, when writing code to protect database fields from unauthorized modification, I generally do so only when it actually makes sense, and the user can actually *see* that his or her attempt to change the value(s) was quietly ignored. *** But I'm still puzzled about the "output redirect" specified in the presentation, but absent from this installation (and yet it still works just fine). Does the "proxyPort" clause on the connector have something to do with it "working just fine" without the "output redirect"? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/6/20 4:28 PM, James H. H. Lampert wrote: > I think I found something, with the help of "MLu" on ServerFault: > > He advised me to try "iptables -L" and "iptables-save" again, only > this time "sudo" them. Hah, sorry about that. Nobody thought of specifying that only root can view the iptables stuff. :) > When I did "iptables -L" under root privileges, I still only got > column headings, but when I did "iptables-save" under root > privileges, I hit what appears to be paydirt: >> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 >> *filter :INPUT ACCEPT [5018099:5766179544] :FORWARD ACCEPT [0:0] >> :OUTPUT ACCEPT [400:2863742410] COMMIT This means "no filtering". You have a firewall, so that's fine. >> # Completed on Mon Jan 6 21:17:22 2020 # Generated by >> iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 *nat >> :PREROUTING ACCEPT [41828:2351495] :INPUT ACCEPT [76356:4167904] >> :OUTPUT ACCEPT [254990:18418937] :POSTROUTING ACCEPT >> [254990:18418937] -A PREROUTING -p tcp -m tcp --dport 443 -j >> REDIRECT --to-ports 8443 COMMIT This means that the NAT table is being used to forward port 443 -> 8443 just like we were all assuming, but hadn't yet proven. >> # Completed on Mon Jan 6 21:17:22 2020 > > Other than the one obvious line near the bottom, >> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports >> 8443 > I'm not entirely sure what all of this means, nor do I remember > what I did to set it up. This definitely means that clients can connect to host:443 and will actually communicate with host:8443. Mystery solved! - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UpIQACgkQHPApP6U8 pFgHWg/9GkBh1aVeCqqUmKd4l8BcBTrYGCEdVf5FxirWHwWTbmqAY5NYwDPqNOEU OzOrdbFr6O4tbrcrQGg78pD/ZqhyuwyTKN+NY41/IOFBegbB7ziHyGMNWt81mWbW n9yYQblEHDkwrdLxu1p6l9DFLsNkWmZxbIE+Ktp8Dyvocv0rfeEh6Ht2jQGOyWKm m4xhgIc9i9ewGglpRoOwJmfSYuHLs8ijw8CA7owfMz+A3brS4RzreNzLW1nxU7m0 1neLHu2e8AFHw0CPb8NAMt4kC1Rf67wyLbxE2umOPIK16V6yIY96fWmkFNqIlHCl tiY2oncn6A9jG4r86W2i1MHMEust8a2d/F/bvL5Yjiw26TMr+T5rL/EFU6debTfW jkFSCS2gFaUM/bBb78d6vQfmpHTj17lP87YK4YJtjQT5/SAXnnty8g7PtOO+jp+W 6gaHYKp1TSYPareexO9NcNd4QM6aWMjMqNgNqiPnggZ6We1Xc+eK7U7kmMpp3hee 7Jggk4oM7G7d8ld1KNW5lRvEGc15E39ZEstFP0UJ78qbHv0ROlh4xoD0lhkW00YB fC4P4RQE4nwCbDRC7hd2vNPPrSKu6IKo/rwTcGl7yPpi0oX1eTg0AYkaxd2MOTX8 o7NemE0CY01Y65Fev7Yir/WRBxuC1wfuJb1U91t8WblAejQV5bU= =z5M1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
Heureka! Actually, I was thinking more "Sokath, his eyes uncovered!" And actually, at this point, I'm thinking I'm better off with Apache httpd handling port 80, since it would only be used for Let's Encrypt, and Let's Encrypt and certbot currently play much more nicely with it than with Tomcat. But that puts at least the next step of this exercise outside the scope of this List. It may be time to view Mr. Schultz's presentation again. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Breakthrough, Re: Let's Encrypt with Tomcat?
James, >> Am 06.01.2020 um 22:28 schrieb James H. H. Lampert >> : >> >> I think I found something, with the help of "MLu" on ServerFault: >> >> He advised me to try "iptables -L" and "iptables-save" again, only this time >> "sudo" them. >> >> When I did "iptables -L" under root privileges, I still only got column >> headings, but when I did "iptables-save" under root privileges, I hit what >> appears to be paydirt: >> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 >> *filter >> :INPUT ACCEPT [5018099:5766179544] >> :FORWARD ACCEPT [0:0] >> :OUTPUT ACCEPT [400:2863742410] >> COMMIT >> # Completed on Mon Jan 6 21:17:22 2020 >> # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 >> *nat >> :PREROUTING ACCEPT [41828:2351495] >> :INPUT ACCEPT [76356:4167904] >> :OUTPUT ACCEPT [254990:18418937] >> :POSTROUTING ACCEPT [254990:18418937] >> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 >> COMMIT >> # Completed on Mon Jan 6 21:17:22 2020 > > Other than the one obvious line near the bottom, >> -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 > I'm not entirely sure what all of this means, nor do I remember what I did to > set it up. Heureka! So you may add the like for Port 80 and you are set for LE! Peter > -- > JHHL > > - > 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
Breakthrough, Re: Let's Encrypt with Tomcat?
I think I found something, with the help of "MLu" on ServerFault: He advised me to try "iptables -L" and "iptables-save" again, only this time "sudo" them. When I did "iptables -L" under root privileges, I still only got column headings, but when I did "iptables-save" under root privileges, I hit what appears to be paydirt: # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 *filter :INPUT ACCEPT [5018099:5766179544] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [400:2863742410] COMMIT # Completed on Mon Jan 6 21:17:22 2020 # Generated by iptables-save v1.4.18 on Mon Jan 6 21:17:22 2020 *nat :PREROUTING ACCEPT [41828:2351495] :INPUT ACCEPT [76356:4167904] :OUTPUT ACCEPT [254990:18418937] :POSTROUTING ACCEPT [254990:18418937] -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 COMMIT # Completed on Mon Jan 6 21:17:22 2020 Other than the one obvious line near the bottom, > -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 I'm not entirely sure what all of this means, nor do I remember what I did to set it up. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
