Comments on: Locking up the valuables: Opt-in security with ForceTLS http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/ Fri, 11 Nov 2011 11:23:21 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: David Dreghorn http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-107035 David Dreghorn Sun, 23 Aug 2009 00:13:44 +0000 http://blog.mozilla.com/security/?p=143#comment-107035 Cheers for the reply (I'm not the most patient of people, ssorry about that). I will leave the add on on, I guess we will have to wait a bit for the websites to catch up, hopefuly they will see this as a excelent chance to improve user safety/security. Sorry for the double posting. Cheers for the reply (I’m not the most patient of people, ssorry about that).

I will leave the add on on, I guess we will have to wait a bit for the websites to catch up, hopefuly they will see this as a excelent chance to improve user safety/security.

Sorry for the double posting.

]]> By: Sid Stamm http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-107019 Sid Stamm Thu, 20 Aug 2009 17:00:52 +0000 http://blog.mozilla.com/security/?p=143#comment-107019 @David Dreghorn: If you think the add-on is not working as expected, or there's a bug, please email the support email address for the add-on listed in AMO (https://addons.mozilla.org/en-US/firefox/addon/12714) and we'll work with you to fix it. Force-TLS doesn't 'upgrade' *all* web sites to HTTPS: it will only upgrade sites that have told your browser they want to opt in, or those sites you have manually entered into the add-on's settings. Since this is a prototype and very new, I don't anticipate many web sites yet tell your browser to upgrade them. @David Dreghorn:
If you think the add-on is not working as expected, or there’s a bug, please email the support email address for the add-on listed in AMO (https://addons.mozilla.org/en-US/firefox/addon/12714) and we’ll work with you to fix it.

Force-TLS doesn’t ‘upgrade’ *all* web sites to HTTPS: it will only upgrade sites that have told your browser they want to opt in, or those sites you have manually entered into the add-on’s settings. Since this is a prototype and very new, I don’t anticipate many web sites yet tell your browser to upgrade them.

]]> By: David Dreghorn http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-107015 David Dreghorn Wed, 19 Aug 2009 23:44:47 +0000 http://blog.mozilla.com/security/?p=143#comment-107015 My last 2 comments were deleted, is there a reason fthey were deleted? The first time I put in my web address and the comment was delted, the 2nd time I left it off but thee link was still there if you clicked on my name (no idea how that happend). My last 2 comments were deleted, is there a reason fthey were deleted? The first time I put in my web address and the comment was delted, the 2nd time I left it off but thee link was still there if you clicked on my name (no idea how that happend).

]]> By: David Dreghorn http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-107010 David Dreghorn Wed, 19 Aug 2009 16:45:56 +0000 http://blog.mozilla.com/security/?p=143#comment-107010 It might be because I am not that quick when it comes to IT, but I can not see any difference. I added the Add-on, but it dont not seem to make any difference as I still got the http version, not the htpps. To get the https version, I had to type in htpps. Is there any point to the add-on if we still need to type in htpps? Will this not cause some people to be vulunrable? If people add the add-on and all they get is the http login, they might just think that this is the only page they can get and just type their info in and not look for the https verision, after all if there is one, the add-on should have taken them to it. It might be because I am not that quick when it comes to IT, but I can not see any difference. I added the Add-on, but it dont not seem to make any difference as I still got the http version, not the htpps. To get the https version, I had to type in htpps.

Is there any point to the add-on if we still need to type in htpps? Will this not cause some people to be vulunrable? If people add the add-on and all they get is the http login, they might just think that this is the only page they can get and just type their info in and not look for the https verision, after all if there is one, the add-on should have taken them to it.

]]> By: David Dreghorn http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-107009 David Dreghorn Wed, 19 Aug 2009 16:23:19 +0000 http://blog.mozilla.com/security/?p=143#comment-107009 It might be because I am not the quickest of people when it comes to IT, but I can not tell if there is any difference. I added the add on, and restarted Firfox to see if it would make any difference to the page, it was still http, not https. When I put in https to the site address, I then got the encrypted version. If we have to put https in, what is the use of the add on? It might be because I am not the quickest of people when it comes to IT, but I can not tell if there is any difference. I added the add on, and restarted Firfox to see if it would make any difference to the page, it was still http, not https. When I put in https to the site address, I then got the encrypted version.

If we have to put https in, what is the use of the add on?

]]> By: Sid Stamm http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-106094 Sid Stamm Tue, 28 Jul 2009 17:44:07 +0000 http://blog.mozilla.com/security/?p=143#comment-106094 @Daniel Veditz: I just finished adding support for private browsing mode in version 1.0.3 of the add-on, and as soon as it is reviewed by AMO, it will be available for download. (If you can't wait, it's available at http://forcetls.sidstamm.com/). @Daniel Veditz: I just finished adding support for private browsing mode in version 1.0.3 of the add-on, and as soon as it is reviewed by AMO, it will be available for download. (If you can’t wait, it’s available at http://forcetls.sidstamm.com/).

]]> By: hugo http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-106093 hugo Tue, 28 Jul 2009 16:47:42 +0000 http://blog.mozilla.com/security/?p=143#comment-106093 "To the browser http://foo and https://foo are different sites." However, not for cookies, right? :) Even if you *manualy* can make SECURE cookie not to be sent to http:// version, http:// version still can set cookies sent to https:// version. This should be fixed. “To the browser http://foo and https://foo are different sites.”

However, not for cookies, right? :)
Even if you *manualy* can make SECURE cookie not to be sent to http:// version, http:// version still can set cookies sent to https:// version.
This should be fixed.

]]> By: Daniel Veditz http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-106092 Daniel Veditz Tue, 28 Jul 2009 15:24:37 +0000 http://blog.mozilla.com/security/?p=143#comment-106092 @jmdesp: We agree, this mechanism is useless for sites which are more concerned about SSL overhead than user safety. Or less snarky, there are already sites which have made the choice to go all SSL, but they still have to worry about their users getting hijacked through that first contact on an insecure network. Important sites like PayPal, Wells Fargo Bank, GMail (if you've set the SSL pref), even our own Mozilla Add-ons site. For sites which have already made this investment this feature would make sure it's not for nothing. @jmdesp: We agree, this mechanism is useless for sites which are more concerned about SSL overhead than user safety. Or less snarky, there are already sites which have made the choice to go all SSL, but they still have to worry about their users getting hijacked through that first contact on an insecure network. Important sites like PayPal, Wells Fargo Bank, GMail (if you’ve set the SSL pref), even our own Mozilla Add-ons site. For sites which have already made this investment this feature would make sure it’s not for nothing.

]]> By: Daniel Veditz http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-106091 Daniel Veditz Tue, 28 Jul 2009 15:17:41 +0000 http://blog.mozilla.com/security/?p=143#comment-106091 @hugo: welcome to the bootstrapping problem. We're making the assumption that the sites people most want to protect from eavesdropping and tampering are those for which they've set up accounts. That means they connected correctly at least once, and this header could be set at that time. In addition, careful users could always add "https://" themselves the first time and avoid that initial redirect. If a .bank TLD gets set up with the properties you propose we can happily support that, too. The two mechanisms could coexist easily. Information stored in a signed DNSSEC record would be another way to communicate this information, but again, that means getting another big technology off the ground before we could build something like this on top of it. As to your other comment: I, too, would prefer blocking insecure content over falling back into insecure "mixed" mode, and the same-origin policy already takes scheme into account. To the browser http://foo and https://foo are different sites. To the site, however, it might be the same content with different entry points and of course attackers will flock to the unguarded entry. @hugo: welcome to the bootstrapping problem. We’re making the assumption that the sites people most want to protect from eavesdropping and tampering are those for which they’ve set up accounts. That means they connected correctly at least once, and this header could be set at that time. In addition, careful users could always add “https://” themselves the first time and avoid that initial redirect.

If a .bank TLD gets set up with the properties you propose we can happily support that, too. The two mechanisms could coexist easily.

Information stored in a signed DNSSEC record would be another way to communicate this information, but again, that means getting another big technology off the ground before we could build something like this on top of it.

As to your other comment: I, too, would prefer blocking insecure content over falling back into insecure “mixed” mode, and the same-origin policy already takes scheme into account. To the browser http://foo and https://foo are different sites. To the site, however, it might be the same content with different entry points and of course attackers will flock to the unguarded entry.

]]> By: Ivan Ristic http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/comment-page-1/#comment-106090 Ivan Ristic Tue, 28 Jul 2009 14:47:39 +0000 http://blog.mozilla.com/security/?p=143#comment-106090 I think the basic idea, that some sites must be SSL-only, is sound. However, if implemented on its own, there will inevitably be ways to bypass it. Today we have too many components doing their own thing, breaking for others security in the process. Several years ago I had this idea of introducing what I called "Secure Browsing Mode", which is a series of measures that makes web applications again. One of the proposed measures was to require SSL for applications that aim to be secure. Another, to make session hijacking impossible. Another, to make CSRF impossible. And so on. Our main weakness is that today there is no such thing as an web application. We only have a set of pages that work together, with some negative security measures (same-origin policies) in place that prevent just any page from interacting from any other page. We need to make web applications first-class citizens on the Web. We need to make it possible to define them, and allow them to control their space, which includes controlling how browsers interact with them too. By making the additional security elective we would allow security-conscientious applications to be more secure, and avoid breaking the Web at the same time. Perhaps the Mozilla team could have a look at the ideas and see if some of them are worth implementing: http://www.modsecurity.org/blog/archives/2006/06/secure_browsing.html Direct link to the PDF: http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf Some of these ideas are being implemented but, again, since the work is done independently, we are not going to benefit to the level we could if the whole thing were designed at once. I think the basic idea, that some sites must be SSL-only, is sound. However, if implemented on its own, there will inevitably be ways to bypass it. Today we have too many components doing their own thing, breaking for others security in the process.

Several years ago I had this idea of introducing what I called “Secure Browsing Mode”, which is a series of measures that makes web applications again. One of the proposed measures was to require SSL for applications that aim to be secure. Another, to make session hijacking impossible. Another, to make CSRF impossible. And so on.

Our main weakness is that today there is no such thing as an web application. We only have a set of pages that work together, with some negative security measures (same-origin policies) in place that prevent just any page from interacting from any other page. We need to make web applications first-class citizens on the Web. We need to make it possible to define them, and allow them to control their space, which includes controlling how browsers interact with them too.

By making the additional security elective we would allow security-conscientious applications to be more secure, and avoid breaking the Web at the same time.

Perhaps the Mozilla team could have a look at the ideas and see if some of them are worth implementing:

http://www.modsecurity.org/blog/archives/2006/06/secure_browsing.html

Direct link to the PDF:
http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf

Some of these ideas are being implemented but, again, since the work is done independently, we are not going to benefit to the level we could if the whole thing were designed at once.

]]>