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)?
