2025-04-11, 01:19 PM
(This post was last modified: 2025-04-11, 01:23 PM by bitstream. Edited 1 time in total.)
We're half way on the same page, half way not :-)
Re: HTTPS/TLS
I understand JF does not offer any kind of HTTPS/SSL/TLS configuration other than the port and providing the cert to be used. I know that not being able to restrict the SSL/TLS version and ciphers to be used, has to be seen as a security risk. Knowing this, it's still better to use HTTPS than to use http without encryption, sending all communication incl. passwords in cleartext. So "don't use JF HTTPS" generally is a bad advice. This needs to be formulated more differentiated.
Re: Integration pattern
The only (if not using an other secure tunnel) acceptable intergration pattern allowing to use http in communication with JF would be to bind JF to the loopback adapter only and have a reverse proxy running on the same machine talking to JF on the second leg. JF then also should be configured to only take requests from the reverse proxy. This is the only way to make sure JF's http port is not exposed to the outside of the machine. Still, that's not perfect, as the http connection could be interfered within the machine. However this would most probably require to take over the machine, where intercepting a http connection isn't the main problem then.
The moment the reverse proxy is not running on the same machine, meaning communication is flowing through a virtual or physical network between the reverse proxy and JF, unencrpyted communication is a severe security risk (passwords are transmitted in clear text and can be intercepte on the network) and using https on JF on the second leg has to be considered far better than using http.
1) Only if reverse proxy and JF are running on the same machine:
pattern A: client -> https -> reverse proxy -> http/loopback -> JF/loopback
https would still be better:
pattern B: client -> https -> reverse proxy -> https/loopback -> JF/loopback
All other scenarios:
pattern C: client -> https -> reverse proxy -> https -> JF
2) If you can't have or don't want a reverse proxy running for what ever reason:
pattern C: client -> https -> JF
This pattern should not be chosen if the machine is exposed to a non-trusted, public or routed network.
However it's far better than
[dont do] pattern D: client -> http -> JF
Finally: Without knowing what SSL/TLS stack JF is using, moderns stacks are expected to support TLS configurability. From what I read in the forum, it seems to be by intention to not add configurability options to JF. Argument is, that there are reverse proxies offering this functionality, so why should JF implement it? Did I get this correct?
While I agree to this if an application runs in an application runner, I'd say it's a best practise today to encrypt communication the moment information leaves the application context. So if JF would come bundled with/in an application runner, I would agree.
Re: Security by obscurity
Is considered a security anti-pattern. Script kiddies or not, scanning the whole portrange of a machine is done in the fraction of a second and moving ports doesn't change anything. This is not going to make JF more or less secure.
Re: HTTPS/TLS
I understand JF does not offer any kind of HTTPS/SSL/TLS configuration other than the port and providing the cert to be used. I know that not being able to restrict the SSL/TLS version and ciphers to be used, has to be seen as a security risk. Knowing this, it's still better to use HTTPS than to use http without encryption, sending all communication incl. passwords in cleartext. So "don't use JF HTTPS" generally is a bad advice. This needs to be formulated more differentiated.
Re: Integration pattern
The only (if not using an other secure tunnel) acceptable intergration pattern allowing to use http in communication with JF would be to bind JF to the loopback adapter only and have a reverse proxy running on the same machine talking to JF on the second leg. JF then also should be configured to only take requests from the reverse proxy. This is the only way to make sure JF's http port is not exposed to the outside of the machine. Still, that's not perfect, as the http connection could be interfered within the machine. However this would most probably require to take over the machine, where intercepting a http connection isn't the main problem then.
The moment the reverse proxy is not running on the same machine, meaning communication is flowing through a virtual or physical network between the reverse proxy and JF, unencrpyted communication is a severe security risk (passwords are transmitted in clear text and can be intercepte on the network) and using https on JF on the second leg has to be considered far better than using http.
1) Only if reverse proxy and JF are running on the same machine:
pattern A: client -> https -> reverse proxy -> http/loopback -> JF/loopback
https would still be better:
pattern B: client -> https -> reverse proxy -> https/loopback -> JF/loopback
All other scenarios:
pattern C: client -> https -> reverse proxy -> https -> JF
2) If you can't have or don't want a reverse proxy running for what ever reason:
pattern C: client -> https -> JF
This pattern should not be chosen if the machine is exposed to a non-trusted, public or routed network.
However it's far better than
[dont do] pattern D: client -> http -> JF
Finally: Without knowing what SSL/TLS stack JF is using, moderns stacks are expected to support TLS configurability. From what I read in the forum, it seems to be by intention to not add configurability options to JF. Argument is, that there are reverse proxies offering this functionality, so why should JF implement it? Did I get this correct?
While I agree to this if an application runs in an application runner, I'd say it's a best practise today to encrypt communication the moment information leaves the application context. So if JF would come bundled with/in an application runner, I would agree.
Re: Security by obscurity
Is considered a security anti-pattern. Script kiddies or not, scanning the whole portrange of a machine is done in the fraction of a second and moving ports doesn't change anything. This is not going to make JF more or less secure.