[
https://issues.apache.org/jira/browse/OFBIZ-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139418#comment-15139418
]
Jacques Le Roux commented on OFBIZ-6849:
----------------------------------------
The most important problem was ecomseo. I just retried (w/o changes) with most
important browsers (last versions) trying both possibilities (though now only
HTTPS should be used)
# https://localhost:8443/ecomseo
all tried browsers work 1st time
# http://localhost:8080/ecomseo
** FF 404, works 2nd time (F5), redirects to https://localhost:8443/ecomseo
** Chrome 404, works 2nd time (F5), redirects to https://localhost:8443/ecomseo
** IE 11 works 404, stays. I guess it's related with HSTS, I will digg that
** Opera 404, works 2nd time (F5), redirects to https://localhost:8443/ecomseo
The difficulty here is that you don't need to login to access ecommerce or
ecomseo (anonymoius access). Though there is any problems with
http://localhost:8080/ecommerce/control/main. So this still needs to be
clarifed but is not blocking
> Use only HTTPS in OFBiz
> -----------------------
>
> Key: OFBIZ-6849
> URL: https://issues.apache.org/jira/browse/OFBIZ-6849
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
> Affects Versions: Trunk
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6849.patch
>
>
> I recently (~4 weeks ago) started the ["Performance over security, is that
> reasonable?"|http://markmail.org/message/ubgacfzfxvlvlqva] thread on dev ML.
> I think I did not explain me well then. I must say it's easy to drown down in
> details with this subject when you want to illustrate the reasons.
> So instead of only answering on the dev ML, I decided it will be good to
> create a Jira task with maybe related tasks, here it is.
> For now I consider it only an improvement, but since it's a security matter
> we can discuss backporting later.
> \\
> ----
> h2. TL;DR
> h3. Performance over security?
> So why was this thread opposing performance and security? First we need to
> understand that here performance stands for HTTP and security for HTTPS.
> h5. Why is HTTP standing for performance?
> Actually is now not much performance difference between the 2 protocols, but
> you can't cache HTTPS requests and it sometimes (inter-continental requests)
> matters.
> h3. And why the question about being reasonable or not?
> I think it's unreasonable to put performance over security. And nowadays you
> are not secure when you use HTTP mixed with HTTPS. Most of the time when you
> mix both is because you want to identity an user using a sessionId. So with
> HTTPS, after the user started with HTTP. As concisely explained Forrest in
> the above referenced thread
> {quote}
> 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.
> {quote}
> It's also well and simply explained (with other things) in [this
> article|http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/]:
> {quote}
> The HTTP spec defines a “Secure” flag for cookies, which instructs the
> browser to only send that cookie value over SSL. If sites set that cookie
> like they’re supposed to, then yes, SSL is helping you out. Most sites don’t,
> however, and browsers will happily send the sensitive cookies over
> unencrypted HTTP. Our hypothetical skeezebag really just needs some way to
> trick you into opening a normal HTTP URL, maybe by e-mailing you a link to
> http://yourbank.com/a-picture-of-ponies-and-rainbows.gif so he can sniff the
> plain-text cookie off your unencrypted HTTP request, or by surreptitiously
> embedding a JavaScript file via some site’s XSS vulnerability.
> {quote}
> Of course if you site is only showing things but nobody has never to
> identify, then you are not at risk and HTTP only is perfect. But with
> ecommerce kind of site or such, it's rarely the case, most of the time users
> need to identify!
> ----
> \\
> So why are people still mixing HTTP and HTTPS on their site? In the 1st
> answer at
> [\[1\]|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#answer-4376]
> Thomas Pornin and others gave some interesting points and answers. At
> [\[2\]|http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/]
> Yves Lafon gave also a good summary even if a bit old now. I took some
> questions/answers from
> [\[3\]|https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything]
> also. So you might check those links by yourself, here is an abstract:
> # *"Some browsers may not support SSL"* Only old Lynx versions, negligible
> # *"Connection initiation requires some extra network roundtrips"* Negligible
> but for sites which serve mostly static contents, see "static content takes a
> hit" below.
> # *"the SSL initial key exchange adds to the latency"* As [completely
> explained
> here|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#comment-6560]:
> "most TLS server use a RSA key and the client part of RSA is cheap (the
> server incurs most of the cost in RSA)". Still better to have [not too short
> sessions as explained
> here|https://stackoverflow.com/questions/149274/http-vs-https-performance]
> # *"static content takes a hit"* You should though store static content
> apart. OFBiz comes with ofbizContentUrl and content.properties for that. But
> you should still use HTTPS. The [complete
> answer|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#comment-6560]
> for the last question (just above this one) also applies here. Also this is
> quite interesting https://www.httpvshttps.com/ and proves *HTTPS can be
> faster than HTTP*
> # *"HTTPS servers must use one IP per server name"* or *"it doesn't work with
> virtual hosts"* This issue has long been solved by [Server Name
> Indication|https://en.wikipedia.org/wiki/Server_Name_Indication] which is
> supported by all major browsers nowadays.
> # *Certificates are expensive* For demos, etc. (ie not for real production
> sites where a certificate is mandatory anyway) but this no longer an issue
> with
> [letsencrypt|https://community.letsencrypt.org/t/frequently-asked-questions-faq]
> # *"Proxy servers cannot cache pages served with HTTPS"* This is the more
> important point. Nowadays this is only a performance problem with
> inter-continental requests. Note that you can use HTTP for static content
> inside OFBiz
> {panel:title=Warning|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> I must say the point 4 is disputable. If for instance you are serving a lot
> of static contents intercontinentally, you should measure and take any
> solution which fits with your case at the moment you measured it (means in
> few years it could change and be negligible)
> {panel}
> [\[1\]
> https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol]
> [\[2\]
> http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it|http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/]
> [\[3\]
> https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything|https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything]
> As \[2\] concluded in 2011:
> {code}
> In the Web of the future the main concern won't just be how fast a site
> loads, but how well it safeguards you and protects your data once it does
> load.
> {code}
> And I you are really interested in every details you should read *[this other
> article from
> 2011|http://vitobotta.com/why-isnt-ssl-on-by-default-for-all-websites/]*. You
> might also notice that there are not much new articles on this subject. I
> still wonder why, I guess because most was already said and it's more to
> people (site developpers) now to take care
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
