[
https://issues.apache.org/jira/browse/OFBIZ-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-6849:
-----------------------------------
Description:
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)"
# *"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.
# *"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]
And I you are really interested in every details you should read *[this 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
was:
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)"
# *"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.
# *"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
[\[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]
And I you are really interested in every details you should read *[this 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
> 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)"
> # *"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.
> # *"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]
> And I you are really interested in every details you should read *[this
> 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)
