It needs to be HTTPS all the time, or HTTPS none of the time.
One of the properties of a TLS connection is data integrity. That is,
you know if data is changed in transit. This is the mechanism that
prevents a person on the network between you and the server to change
your traffic, man-in-the-middle as I'm sure everyone has heard or knows
about. If you're switching between HTTPS and HTTP based on some
criteria, an attacker can leverage that to trick the user into all kind
of things. Including changing all the embedded HTTPS URLs sent to the
user's browser during a switch from HTTP to HTTPS, back to HTTP. Chrome
would throw up all kinds of warnings about this fortunately.
Secondly, you're then putting the burden of security on the person
authoring the request-map to define that criteria for switching.
Frankly, if you're operating any web application that handles PII on the
Internet, and not using HTTPS, you're putting all your users at risk,
and you need to change that.
There is a great tool for quickly checking the basic security controls
that can be enabled for web servers, take a look at my site:
https://securityheaders.io/?q=https%3A%2F%2Fpartner.fidelissd.com%2F&hide=on
-Forrest
On 1/2/16 3:59 PM, Scott Gray wrote:
I'm too lazy to read all the links but I think we can make some
straightforward changes to improve the situation:
1. Once a user is on https, all links generated should use https
2. If a user is on http, then that's fine and we just need to ensure that
when they switch to https (during login or any other sensitive activities)
that we're able to transfer any existing session information over to a
secure session with a new session id.
Is there any more to it?
Regards
Scott
On 3 January 2016 at 12:14, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
Hi,
You maybe noticed that I began to work on securing and keeping OFBiz
secured better by proposing tools to use and share with the community
https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure
This started after I was confronted with the "The 2015 infamous Java
unserialize vulnerability". As explained in the wiki page, there were also
3 other points I wanted to address:
* Java<
https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check
* JavaScript<
https://cwiki.apache.org/confluence/display/OFBIZ/About+retire.js>
* HTTP headers<https://cyh.herokuapp.com/cyh>
I already worked in end of 2013 on updating 3rd party Java lib OFBiz
depends on. It's a tedious work but mostly without surprises, it's only a
matter of rightly upgrading external libs (as much as we can).
I decided to postpone the work on JavaScript libs (it's tedious and mostly
straigthforward as well) because I thought that resolving the issues on
HTTP headers would be much simpler and it was new to me (more fun). So far
I also thought it was a minor point regarding security. I was wrong! OK, it
gets now a bit more complicated, I will try my best to explain in as less
as possible words.
I did not cross much issues, until I began to work on securing cookies. I
committed r1719762 when I decided I should have a look at OFBIZ-6655. I
then reverted r1719762 and tried to commit the proposed patches there, but
finally reverted them because of an issue in ecommerce and reapplied
r1719762. Then Pierre Smits noticed an issue on trunk demo in ecommerce. To
solve it I naively created
https://issues.apache.org/jira/browse/INFRA-10973 and dug the wrong way.
Then Deepak called me because he found an issue with r1719762 and we
decided we should revert, and he did at r1722379 (I did not get a chance
yet to check, but I trust Deepak).
I was writing this email (for few hours) when Scott just wrote
https://issues.apache.org/jira/browse/OFBIZ-6111?focusedCommentId=15076677,
and I agree with him.
But that's not the whole point of this email. While working on securing
cookies, I stumbled upon this blog post
http://resources.infosecinstitute.com/cookies-secure-flag-undesired-behavior-modern-browsers/.
Long story short, you can't have the cake and eat it too. Or rather you
can't use HTTP and be secure if you also use sessions (this is what OFBiz
ecommerce does). I wrote in the title about "Performance over security".
Because the only remaining reason nowadays people would want HTTP is for
performance caching adds.
There is some good articles about that:
http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/
https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything
https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol
To summarize with letsencrypt
https://community.letsencrypt.org/t/frequently-asked-questions-faq
and Server Name Indication
https://en.wikipedia.org/wiki/Server_Name_Indication
https://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/
most of the other concerns are off (we use TLS for a while now in OFBiz)
So I'd like to remove, or rather make optional, HTTP in OFBiz. Though I
did not check technical detail yet, people who really prefer performance
over security would be able to use it through a properties in
url.properties.
You should be interested by
https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
as well
Opinions?
Jacques
PS: nobody knows what really happened to Ian Murdock (it's blurred in
news, I know his family wants discretion)?
