[aur-general] Securing the AUR website
Hi TUs, the AUR still handles user logins and sessions in a insecure way that can easily be exploited. The last approach to use https by default was denied a long time ago. But I hope you guys will reconsider this decision. To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default * Set session.cookie_secure = 1 in your php.ini * If you use setcookie() make sure to set the secure parameter to true * If you don't require any javascript to access your session data it's also a good idea to set all cookie to httponly (again via php.ini and if you use setcookie() directly) The optional https access as we have now wont work here. Even if you never forget to add the s to http when you login session data is also transferred via http. So once you click a non-https link to the AUR it would be possible for an attacker to hijack your session. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Fri, Aug 05, 2011 at 11:36:06PM +0200, Pierre Schmitz wrote:
Hi TUs,
the AUR still handles user logins and sessions in a insecure way that can easily be exploited. The last approach to use https by default was denied a long time ago. But I hope you guys will reconsider this decision.
The only thing that was denied is enforcing HTTPs. HTTPs has been enabled by default some time ago [1], [2], [3], [4]. It's just not live yet. There will be another AUR release, soon, though.
To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
* Set session.cookie_secure = 1 in your php.ini * If you use setcookie() make sure to set the secure parameter to true
See above.
* If you don't require any javascript to access your session data it's also a good idea to set all cookie to httponly (again via php.ini and if you use setcookie() directly)
That kind of makes sense :)
The optional https access as we have now wont work here. Even if you never forget to add the s to http when you login session data is also transferred via http. So once you click a non-https link to the AUR it would be possible for an attacker to hijack your session.
That is kind of fixed in Git (again, check [1], [2], [3] and [4]). [1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
On Fri, 5 Aug 2011 23:54:57 +0200, Lukas Fleischer wrote:
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
Seriously the overhead is negligible, on client as on sever side. Even for those who don't have an AUR account, https would prevent anybody else injecting code. But those wont matter anyway because securing those who have an account should be priority. At least ensure that cookies are never sent unencrypted.
That is kind of fixed in Git (again, check [1], [2], [3] and [4]).
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
None of these patches fixes the issue that session data will still be send unencrypted. This is a real world issue; even if you login using https it wont be unlikely that you later will visit the site unencrypted (by clicking on a link or some resource you forgot to send via https). Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, Aug 06, 2011 at 12:09:34AM +0200, Pierre Schmitz wrote:
On Fri, 5 Aug 2011 23:54:57 +0200, Lukas Fleischer wrote:
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
Seriously the overhead is negligible, on client as on sever side. Even for those who don't have an AUR account, https would prevent anybody else injecting code. But those wont matter anyway because securing those who have an account should be priority. At least ensure that cookies are never sent unencrypted.
Yeah, that is no reason for disabling plain HTTP, still. You have a valid point with the unencrypted cookies though. I will probably fix this when doing the next AUR release (which will be pretty soon).
That is kind of fixed in Git (again, check [1], [2], [3] and [4]).
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
None of these patches fixes the issue that session data will still be send unencrypted. This is a real world issue; even if you login using https it wont be unlikely that you later will visit the site unencrypted (by clicking on a link or some resource you forgot to send via https).
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
2011/8/5 Lukas Fleischer <archlinux@cryptocrack.de>
On Sat, Aug 06, 2011 at 12:09:34AM +0200, Pierre Schmitz wrote:
On Fri, 5 Aug 2011 23:54:57 +0200, Lukas Fleischer wrote:
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
Seriously the overhead is negligible, on client as on sever side. Even for those who don't have an AUR account, https would prevent anybody else injecting code. But those wont matter anyway because securing those who have an account should be priority. At least ensure that cookies are never sent unencrypted.
Yeah, that is no reason for disabling plain HTTP, still. You have a valid point with the unencrypted cookies though. I will probably fix this when doing the next AUR release (which will be pretty soon).
That is kind of fixed in Git (again, check [1], [2], [3] and [4]).
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
None of these patches fixes the issue that session data will still be send unencrypted. This is a real world issue; even if you login using https it wont be unlikely that you later will visit the site unencrypted (by clicking on a link or some resource you forgot to send via https).
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
IMHO, I think that some HTTPs is better than nothing and that some HTTPs is better than HTTPsing everything. So, I think that Lukas' solution is good for now and it can be adjusted later if needed. -- Estêvão Valadão
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default. Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default.
Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round.
Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP.
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200:
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default.
Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round.
Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP.
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults: archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR. Best regards, Philipp
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200:
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default.
Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round.
Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP.
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200:
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway.
I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default.
Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round.
Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP.
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR. Regards, Philipp
On 01/09/11 11:51, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200:
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default. Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR. HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date. When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Regards, Philipp
When I visit aur.archlinux.org I get the https version (chromium). Try to clean your firefox cache...
On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...]
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though.
On 01/09/11 12:01, Lukas Fleischer wrote:
On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...]
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR. HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date. When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR. Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though. There's an option if firefox that should use https under Advanced > Encryption tab in Preferences, if I remember that correctly.
Excerpts from Lukas Fleischer's message of 2011-09-01 13:01:50 +0200:
On Thu, Sep 01, 2011 at 12:51:24PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote: [...]
I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though.
So it's a firefox default to try http first and the other parts of the website redirect?
Am 01.09.2011 13:01, schrieb Lukas Fleischer:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though.
I'd like to remind everyone again that Arch Linux is now included in the https-everywhere default rules, see [1]. This will always redirect you to https on every Arch Linux site (even releng, www, planet, where it isn't actually needed). [1] https://www.eff.org/https-everywhere/
Excerpts from Thomas Bächler's message of 2011-09-01 14:16:20 +0200:
Am 01.09.2011 13:01, schrieb Lukas Fleischer:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR.
HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date.
When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Yeah, you request the HTTP version (your browser does this automatically if you skip the protocol part), so this is kind of expected behaviour. We could introduce an HTTPs redirect for the AUR home page. Not sure if that is the right thing to do, though.
I'd like to remind everyone again that Arch Linux is now included in the https-everywhere default rules, see [1]. This will always redirect you to https on every Arch Linux site (even releng, www, planet, where it isn't actually needed).
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
On Thu, Sep 1, 2011 at 5:55 PM, Philipp Überbacher <hollunder@lavabit.com>wrote:
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
The rules are included with the plugin and you benefit from its functionalities with a lot of other sites. But I do have installed this plugin because of the AUR. -- Cédric Girard
Excerpts from Cédric Girard's message of 2011-09-01 18:05:36 +0200:
On Thu, Sep 1, 2011 at 5:55 PM, Philipp Überbacher <hollunder@lavabit.com>wrote:
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
The rules are included with the plugin and you benefit from its functionalities with a lot of other sites. But I do have installed this plugin because of the AUR.
I've installed it now and it works fine, thanks for the tip. What I wonder is whether it's worth the trouble to register the site, maintain the rules and have users install a plugin. I'm also sceptical because this is an opt-in solution for a security feature, which means that a lot of users won't benefit. Thanks, Philipp
On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher <hollunder@lavabit.com> wrote:
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
I don't really understand why it's so important to break existing links by forcing everyone onto the https page. What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats? -- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
On Thu, Sep 1, 2011 at 8:15 PM, Gordon JC Pearce <gordonjcp@gjcp.net> wrote:
I don't really understand why it's so important to break existing links by forcing everyone onto the https page.
And what in rewriting http://aur.archlinux.org/foo into https://aur.archlinux.org/foo is breaking links ?
What happens if you *don't want to use https*?
I still have difficulties to understand why people would like to purposely avoid using https. Do you ask the admin of the server you have to connect to, to enable rlogin to be able to connect to there server insecurely as well ? -- Cédric Girard
On Thu, 1 Sep 2011 20:36:34 +0200 Cédric Girard <girard.cedric@gmail.com> wrote:
What happens if you *don't want to use https*?
I still have difficulties to understand why people would like to purposely avoid using https.
I still have difficulties understanding why people would purposely use https... What's the benefit? -- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
2011/9/2 Gordon JC Pearce <gordonjcp@gjcp.net>:
On Thu, 1 Sep 2011 20:36:34 +0200 Cédric Girard <girard.cedric@gmail.com> wrote:
What happens if you *don't want to use https*?
I still have difficulties to understand why people would like to purposely avoid using https.
I still have difficulties understanding why people would purposely use https... What's the benefit?
-- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
's' stands for Secure. Maybe security is a good reason.
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1 <rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good. What happens if you're using a password you don't care about for AUR? -- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
2011/9/3 Gordon JC Pearce <gordonjcp@gjcp.net>:
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1 <rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good.
What happens if you're using a password you don't care about for AUR?
-- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
Do you mean a password that is easy to be cracked? This would be a case for feature request for password policy.
On Sat, Sep 03, 2011 at 02:55:50PM +0100, Gordon JC Pearce wrote:
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1 <rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good.
What happens if you're using a password you don't care about for AUR?
This is by no way an argument... What happens if *at least* one person cares about its AUR password out there? And anyway, having an AUR account hijacked could be damageable to a lot of people. And would you really be ok if someone popped up a fake AUR website at your browser? (let's say in Syria...) Obviously, your browser won't notice anything if you're using plain old HTTP. And seriously, you must be logging in to a bunch of website every day (be it your webmail, your Twitter/G+/whatever); are you really, deliberately using HTTP there? If you lived in China, Libya or Syria, you wouldn't... The current SSL system has some weaknesses, most notably being forced to trust a tremendous amount of CAs. But then, why stick to something that's more than 15 years old, when there is an alternative that offers you encryption and makes sure that you talk to the real server? -- "C'est mieux, mais il y a plus cher ailleurs" : ____ _ _ _ _ ___ _ / ___| \ | | | | | / / | (_)_ __ _ ___ __ | | _| \| | | | |/ /| | | | '_ \| | | \ \/ / | |_| | |\ | |_| / / | |___| | | | | |_| |> < \____|_| \_|\___/_/ |_____|_|_| |_|\__,_/_/\_\ GNU/Linux fan && Archlinux user
On 03/09/11 14:55, Gordon JC Pearce wrote:
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1<rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good.
What happens if you're using a password you don't care about for AUR?
If you are using such password then you are putting AUR at risk because if your password can be easily cracked there is a possibility that an attacker would be able to compromise the whole AUR service using your account (see recent news about kernel.org [1] [2] ) and that will not be good at all. So please use reasonably strong password even if you don't care about AUR yourself... (HTTPS means HTTP over SSL, so it encrypts your COMMUNICATION - it will not make your AUR password any more hack-proof if your password is weak) Is there any particular problem why you can't/don't want to use HTTPS? If yes, we may be able to help you... [1] - http://kernel.org <http://kernel.org/> [2] - http://pastebin.com/BKcmMd47
On Sat, 03 Sep 2011 15:49:30 +0100 Matej Ľach <matej.lach@gmail.com> wrote:
On 03/09/11 14:55, Gordon JC Pearce wrote:
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1<rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good.
What happens if you're using a password you don't care about for AUR?
If you are using such password then you are putting AUR at risk because if your password can be easily cracked there is a possibility that an
I didn't say it could be "easily cracked". I said it's a password that I don't particularly care if I run up against the tiny, vanishingly small chance that anyone is bored enough to somehow tap into my LAN and sniff it.
attacker would be able to compromise the whole AUR service using your
Is there any particular problem why you can't/don't want to use HTTPS? If yes, we may be able to help you...
One is that https is painfully slow over slow or unreliable connections (GPRS springs to mind; 3G service is patchy here). The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled. So, the only way to use AUR from (say) Google is to search for a package, click on it, copy the address from the bar, click on the https login link, log in (since even if you're logged in, visiting the http page seems to log you out), then paste the address you got from the search engine into the address bar, edit it to go to https, then hit return. This is hardly a seamless user experience, but it ought to be trivial to fix. Sort it the fuck out. If you want me to put my money where my mouth is and contribute some code, then just ask. -- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
On 03/09/11 16:49, Gordon JC Pearce wrote:
On Sat, 03 Sep 2011 15:49:30 +0100 Matej Ľach<matej.lach@gmail.com> wrote:
On 03/09/11 14:55, Gordon JC Pearce wrote:
On Sat, 3 Sep 2011 01:18:58 -0300 rafael ff1<rafael.f.f1@gmail.com> wrote:
's' stands for Secure. Maybe security is a good reason.
Oh, okay, so you put an "S" in and it waves the magic "secure" stick. Very good.
What happens if you're using a password you don't care about for AUR?
If you are using such password then you are putting AUR at risk because if your password can be easily cracked there is a possibility that an I didn't say it could be "easily cracked". I said it's a password that I don't particularly care if I run up against the tiny, vanishingly small chance that anyone is bored enough to somehow tap into my LAN and sniff it.
attacker would be able to compromise the whole AUR service using your Is there any particular problem why you can't/don't want to use HTTPS? If yes, we may be able to help you... One is that https is painfully slow over slow or unreliable connections (GPRS springs to mind; 3G service is patchy here). The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
So, the only way to use AUR from (say) Google is to search for a package, click on it, copy the address from the bar, click on the https login link, log in (since even if you're logged in, visiting the http page seems to log you out), then paste the address you got from the search engine into the address bar, edit it to go to https, then hit return. This is hardly a seamless user experience, but it ought to be trivial to fix.
Sort it the fuck out.
If you want me to put my money where my mouth is and contribute some code, then just ask.
""I didn't say it could be "easily cracked"."" I didn't say that you said such thing. It's just my assuming that if you don't care as much about it, it may be more vulnerable... I am sure devs are working hard to make AUR more secure, but also more useable than before, just give them more time. You can also use some sort of plugin for your browser that will transfer you form Google to HTTPS AUR automatically. -- Support Free and Open Source Software -- www.fsf.org -- Join Us Today! _ _ _ _ _ _ / \ _ __ ___| |__ | | (_)_ __ _ ___ __ | | | |___ ___ _ __ / _ \ | '__/ __| '_ \| | | | '_ \| | | \ \/ / | | | / __|/ _ \ '__| / ___ \| | | (__| | | | |___| | | | | |_| |> < | |_| \__ \ __/ | /_/ \_\_| \___|_| |_|_____|_|_| |_|\__,_/_/\_\ \___/|___/\___|_| -- www.matej-lach.net --
Am Sat, 3 Sep 2011 16:49:21 +0100 schrieb Gordon JC Pearce <gordonjcp@gjcp.net>:
So, the only way to use AUR from (say) Google is to search for a package, ...
Why do you need Google to search the AUR? I do it either with the AUR search function or with a wrapper like yaourt or aurbuild. Heiko
On Sat, 3 Sep 2011 20:20:57 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 3 Sep 2011 16:49:21 +0100 schrieb Gordon JC Pearce <gordonjcp@gjcp.net>:
So, the only way to use AUR from (say) Google is to search for a package, ...
Why do you need Google to search the AUR? I do it either with the AUR search function or with a wrapper like yaourt or aurbuild.
The AUR search function doesn't necessarily work very well, and aurbuild/yaourt/clyde et al don't show you the comments on a package. -- Gordon JC Pearce MM0YEQ <gordonjcp@gjcp.net>
Am Sat, 3 Sep 2011 20:25:41 +0100 schrieb Gordon JC Pearce <gordonjcp@gjcp.net>:
The AUR search function doesn't necessarily work very well, and aurbuild/yaourt/clyde et al don't show you the comments on a package.
For me the AUR search function has worked perfectly for me so far, and yaourt shows you the latest comments if you run yaourt -S <packagename>. Heiko
On 3 September 2011 23:49, Gordon JC Pearce <gordonjcp@gjcp.net> wrote:
One is that https is painfully slow over slow or unreliable connections (GPRS springs to mind; 3G service is patchy here). The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
So, the only way to use AUR from (say) Google is to search for a package, click on it, copy the address from the bar, click on the https login link, log in (since even if you're logged in, visiting the http page seems to log you out), then paste the address you got from the search engine into the address bar, edit it to go to https, then hit return. This is hardly a seamless user experience, but it ought to be trivial to fix.
Sort it the fuck out.
If you want me to put my money where my mouth is and contribute some code, then just ask.
You may want to file a bug report against the AUR project (or the entire site) at http://bugs.archlinux.org/ If I just want to browse a domain or subdomain as a guest I wouldn't want to deal with httpS because (1) it slows down my inherently slow connection (think GPRS/EDGE/2G) and (2) I'm not even logged in to want to protect any kind of credential. As it is currently, the Arch Linux sites are enforcing HTTPS and so even if I don't want SECURE, I have to deal with it. I didn't speak up against this before because (1) I wasn't surfing around much and (2) I didn't think my opinion/case would matter and (3) I don't even have the sufficient technical knowledge to debate this sort of thing. At the end of the day, though, SECURE for logins is definitely good, but a lot of sites give the user an option to either disable or enable httpS, eg. Google (GMail; GMail for Mobile) and WordPress. I also know some sites where they only redirect "paying" or "deluxe" users to HTTPS after/during login. So even if you don't care about your password, it's good to have HTTPS, just to be safe. -- GPG/PGP ID: 8AADBB10
Hi, On Mon, Sep 5, 2011 at 1:46 PM, Ray Rashif <schiv@archlinux.org> wrote:
it slows down my inherently slow connection (think GPRS/EDGE/2G)
Do you have any figures to support this? I would be interested to see what the impact of HTTPS on the client side is. -- Cédric Girard
On Mon, 5 Sep 2011 13:55:38 +0200, Cédric Girard wrote:
Hi,
On Mon, Sep 5, 2011 at 1:46 PM, Ray Rashif <schiv@archlinux.org> wrote:
it slows down my inherently slow connection (think GPRS/EDGE/2G)
Do you have any figures to support this? I would be interested to see what the impact of HTTPS on the client side is.
Me too. We'd need some numbers to back this argument. I also wonder how many are really affected by having such a slow connection that this would actually matter. I wouldn't be surprised if this number is really low. I think I already posted all arguments to this thread. So far the only argument against ssl consider valid is decrease of performance. Maybe someone could do some test on this; e.g. check how many bits are transferred using https vs http. Don't forget to take http keep-alive into consideration here. Whatever the outcome of this is, we will most likely spend most of the time in server side processing (sql queries, php). So instead of shutting down ssl we might want to optimize that at first. There are also some things you can tune on web server level (e.g. choosing a faster cipher etc.) At the time I switched to https only for archlinux.de I did some tests and research. At least I couldn't notice any difference in load time using a quite slow connection. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 5 September 2011 20:35, Pierre Schmitz <pierre@archlinux.de> wrote:
On Mon, 5 Sep 2011 13:55:38 +0200, Cédric Girard wrote:
Hi,
On Mon, Sep 5, 2011 at 1:46 PM, Ray Rashif <schiv@archlinux.org> wrote:
it slows down my inherently slow connection (think GPRS/EDGE/2G)
Do you have any figures to support this? I would be interested to see what the impact of HTTPS on the client side is.
Me too. We'd need some numbers to back this argument. I also wonder how many are really affected by having such a slow connection that this would actually matter. I wouldn't be surprised if this number is really low.
It just feels slower. I think the amount of data transferred does not look that much bigger when you have at least a 512Kbps, but browsing is indeed slower. Take, for eg., GMail for Mobile on my phone has HTTPS disabled, and when enabling it warns that "more data will be used". A 128Kbps unstable connection eg. over the GSM network will struggle with an SSL-encrypted website far away from the user's ISP/region due to the inevitable added latency of that kind of network. However, you are right, there is no empirical evidence until I log my connection to one of the Arch Linux sites with and without SSL. I will try and do this soon. In the meantime, these are Google results that you might've already come across: http://support.microsoft.com/kb/150031 http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose http://serverfault.com/questions/43692/how-much-of-a-performance-hit-for-htt... -- GPG/PGP ID: 8AADBB10
Am 03.09.2011 17:49, schrieb Gordon JC Pearce:
The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix.
On Mon, Sep 5, 2011 at 2:44 PM, Thomas Bächler <thomas@archlinux.org> wrote:
This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix.
This bug is already open (FS#25757) and a patch has been submitted: https://mailman.archlinux.org/pipermail/aur-dev/2011-August/001864.html -- Cédric Girard
On Mon, Sep 05, 2011 at 02:44:29PM +0200, Thomas Bächler wrote:
Am 03.09.2011 17:49, schrieb Gordon JC Pearce:
The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix.
Do not open another ticket, please. There's FS#25757 [1] already and I sent a patch addressing that bug to aur-dev [2]. I will push that and update our live setup as soon as I get round to it. [1] https://bugs.archlinux.org/task/25757 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-August/001864.html
Am 05.09.2011 14:51, schrieb Lukas Fleischer:
On Mon, Sep 05, 2011 at 02:44:29PM +0200, Thomas Bächler wrote:
Am 03.09.2011 17:49, schrieb Gordon JC Pearce:
The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix.
Do not open another ticket, please. There's FS#25757 [1] already and I sent a patch addressing that bug to aur-dev [2]. I will push that and update our live setup as soon as I get round to it.
[1] https://bugs.archlinux.org/task/25757 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-August/001864.html
No point to send the patch I just created then (there wasn't anything in aur.git). While looking at it, I noticed that in the action="..." in the login form, there should also be htmlentities or similar around $_SERVER['REQUEST_URI']. Thanks anyway.
On Mon, Sep 05, 2011 at 03:01:03PM +0200, Thomas Bächler wrote:
Am 05.09.2011 14:51, schrieb Lukas Fleischer:
On Mon, Sep 05, 2011 at 02:44:29PM +0200, Thomas Bächler wrote:
Am 03.09.2011 17:49, schrieb Gordon JC Pearce:
The other is that switching to https has left AUR in a fundamentally broken state. If you search for a package on AUR with any of the significant search engines, they return an http link. You can't do anything with this, though, because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING HTTPS AND HTTPS IS TEH AWSUM!!!!11!!11!" message. Now, if clicking on that took you *to the same page but with https* that would be fine, but it doesn't. It unceremoniously dumps you on the index page for AUR, with no way to get back to the package that you googled.
This is a detail you could have shared in your first post and this discussion would have been a lot shorter. This is a bug, it belongs to the bugtracker and it is (as far as I can see) trivial to fix.
Do not open another ticket, please. There's FS#25757 [1] already and I sent a patch addressing that bug to aur-dev [2]. I will push that and update our live setup as soon as I get round to it.
[1] https://bugs.archlinux.org/task/25757 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-August/001864.html
No point to send the patch I just created then (there wasn't anything in aur.git). While looking at it, I noticed that in the action="..." in the login form, there should also be htmlentities or similar around $_SERVER['REQUEST_URI'].
The patch [1] should be live now. Fixed the other issue you mentioned as well [2] and pushed an updated message catalog to Transifex. Any remaining bugs should be reported to our bug tracker [3]. [1] http://projects.archlinux.org/aur.git/commit/?id=a00e5b04 [2] http://projects.archlinux.org/aur.git/commit/?id=20b20c20 [3] https://bugs.archlinux.org/index.php?project=2
On 3 September 2011 09:29, Gordon JC Pearce <gordonjcp@gjcp.net> wrote:
On Thu, 1 Sep 2011 20:36:34 +0200 Cédric Girard <girard.cedric@gmail.com> wrote:
What happens if you *don't want to use https*?
I still have difficulties to understand why people would like to purposely avoid using https.
I still have difficulties understanding why people would purposely use https... What's the benefit?
I personally don't like "https everywhere" because its overhead is significant for slow connections which I have to deal with. However, I'm all for "https logins" because I wouldn't want my information to be intercepted easily. -- GPG/PGP ID: 8AADBB10
Excerpts from Gordon JC Pearce's message of 2011-09-01 20:15:28 +0200:
On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher <hollunder@lavabit.com> wrote:
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
I don't really understand why it's so important to break existing links by forcing everyone onto the https page.
What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats?
It shouldn't be enforced, it should be the default. But you're right, it seems it is enforced in some cases, with the redirect on bugs.archlinux.org for example. In this case the login is on the main page, which is probably the reason for the redirect. It's really somewhat confusing, in the meantime I start to think that optimally both would be available and the browser settings should be the place to decide (in general).
2011/9/1 Philipp Überbacher <hollunder@lavabit.com>:
Excerpts from Gordon JC Pearce's message of 2011-09-01 20:15:28 +0200:
On Thu, 01 Sep 2011 17:55:57 +0200 Philipp Überbacher <hollunder@lavabit.com> wrote:
Do I understand it correctly that https-everywhere goes through a lot of trouble (browser-plugin with whitelist and custom rules for every page) for what could be achieved by simply defaulting to https?
I don't really understand why it's so important to break existing links by forcing everyone onto the https page.
What happens if you *don't want to use https*? Why are the Arch webby bods forcing this nanny-state twatmuppetry down our throats?
It shouldn't be enforced, it should be the default. But you're right, it seems it is enforced in some cases, with the redirect on bugs.archlinux.org for example. In this case the login is on the main page, which is probably the reason for the redirect. It's really somewhat confusing, in the meantime I start to think that optimally both would be available and the browser settings should be the place to decide (in general).
I normally look for AUR packages in my google search engine, in case I'm not already in AUR interface. Since https is the default login, google search find the http interface. That's not much bad, but if I want to login after that, I can't just mouse-click the new "http login disabled" message. IMHO, it would be nice to have a URL in front of this warning that forwards to https in the same page you are at the moment, instead of going to AUR Home. Example: http://aur.archlinux.org/packages.php?ID=41362 # goes to https://aur.archlinux.org/packages.php?ID=41362 -- Rafael
Am Thu, 1 Sep 2011 19:57:51 -0300 schrieb rafael ff1 <rafael.f.f1@gmail.com>:
I normally look for AUR packages in my google search engine, in case I'm not already in AUR interface. Since https is the default login, google search find the http interface. That's not much bad, but if I want to login after that, I can't just mouse-click the new "http login disabled" message. IMHO, it would be nice to have a URL in front of this warning that forwards to https in the same page you are at the moment, instead of going to AUR Home. Example: http://aur.archlinux.org/packages.php?ID=41362 # goes to https://aur.archlinux.org/packages.php?ID=41362
There's already a feature request for this: https://bugs.archlinux.org/task/25757?project=2 Heiko
On 09/01/11 18:57, rafael ff1 wrote:
I normally look for AUR packages in my google search engine, in case I'm not already in AUR interface. Since https is the default login, google search find the http interface.
Can we convince Google-search to link to the HTTPS version, I wonder? -Isaac
On 01/09/11 11:51, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-09-01 12:32:03 +0200:
On Thu, Sep 01, 2011 at 12:13:53PM +0200, Philipp Überbacher wrote:
Excerpts from Lukas Fleischer's message of 2011-08-06 12:14:14 +0200:
On Sat, Aug 06, 2011 at 11:10:48AM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 02:29:13 +0200, Lukas Fleischer wrote:
Agreed. I'm still against completely disabling HTTP. We will use HTTPs for all links by default so there shouldn't be any users unintentionally pasting HTTP links anywhere. Malicious links might still be an issue but observant users should be aware of that. And using secure cookies should fix that, anyway. I didn't tell to disable HTTP. Of course you add a redirect there and you might even add the HSTS header. It's not only about links, also people will just typoe in "aur.archlinux.org" into their browser bar and that will open http by default. Well, "Redirect all http traffic to https by default" sounded to me like disabling plain HTTP. Perhaps I took this too literally.
Anyway, I see I am talking to walls here. Sometimes I wonder why there is so much resistance against encryption. One would think it was the other way round. Again, and I'm not going to repeat this... I am not against enabling encryption and I am not against making it the default. All I said is that we shouldn't turn down HTTP. I sadly followed this discussion only remotely when it was ongoing, so I have to ask: The agreed upon solution for now is to default to http and only allow login from https? At least that's how it is at the moment and the http default feels a bit weird to me. When I can only log in with https I get the feeling I should use https and wonder why it isn't the default. I had a look at other parts of the Arch Linux website as well, here's an overview of the defaults:
archlinux.org -> http -> no login anyway bbs.archlinux.org -> https -> separate login page wiki.archlinux.org -> https -> separate login page bugs.archlinux.org -> https -> login on main page aur.archlinux.org -> http -> login on main page
As you can see, AUR is the fish out of water here, login is on the arrival page, but you can't log in by default. I'm sorry to make the suggestion this late, but I'd vote for https as default for AUR. HTTPs is the default - unless you request the HTTP version explicitly. I know that some of the navigation bar links aren't updated yet. I sent a patch for Flyspray to Pierre, and also asked him to update the header include used in our cgit setup. It should be only a matter of time until all links are up-to-date. When I type aur.archlinux.org in firefox I get the http version, that's what I mean by default. Thanks for your efforts to secure AUR.
Regards, Philipp
This firefox extension works for me - HTTPS finder; https://addons.mozilla.org/en-us/firefox/addon/https-finder/
On 08/06/2011 12:54 AM, Lukas Fleischer wrote:
To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
That reason is a bit childish. We had this discussion 1 year ago and only you and Loui were against. Seriously now, why you are against https? Do you use some aur helper that is broken and uses http and cannot handle redirect well? -- Ionuț
On Sat, Aug 06, 2011 at 01:16:45AM +0300, Ionut Biru wrote:
On 08/06/2011 12:54 AM, Lukas Fleischer wrote:
To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
That reason is a bit childish. We had this discussion 1 year ago and only you and Loui were against.
Seriously now, why you are against https? Do you use some aur helper that is broken and uses http and cannot handle redirect well?
Dude, please stick to the facts. Iirc, I didn't even interfere in the last HTTPs discussion and I nowhere mentioned being against HTTPs. I am totally for making HTTPs the default, I'm just against enforcing it. As you can see, I even committed a few patches replacing all links the AUR ever spits out by HTTPs ones. Everything else is only a matter of server configuration and I am against disabling plain HTTP here. Is there any *real* reason to do that? Even archweb doesn't do that and I don't understand the concerns here. Every half-attentive should be perfectly fine with how we do it in current master. And in case you're really, really paranoid, just setup a proxy that blocks HTTP connections to the AUR. Oh, and by the way. I don't use any AUR helper at all. Just to say that.
On Sat 06 Aug 2011 02:18 +0200, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:16:45AM +0300, Ionut Biru wrote:
On 08/06/2011 12:54 AM, Lukas Fleischer wrote:
To prevent session hijacking, mtm attacks or whatnot I'd recommend the following: * Redirect all http traffic to https by default
We won't do that. HTTPs will be the default but we won't force users to use HTTPs. If you decide to use HTTP intentionally, we won't prevent you from doing so. HTTPs implies an unnecessary overhead and there's no point in forcing everybody to use HTTPs even if one doesn't even have an AUR account.
That reason is a bit childish. We had this discussion 1 year ago and only you and Loui were against.
Seriously now, why you are against https? Do you use some aur helper that is broken and uses http and cannot handle redirect well?
Dude, please stick to the facts. Iirc, I didn't even interfere in the last HTTPs discussion and I nowhere mentioned being against HTTPs. I am totally for making HTTPs the default, I'm just against enforcing it. As you can see, I even committed a few patches replacing all links the AUR ever spits out by HTTPs ones. Everything else is only a matter of server configuration and I am against disabling plain HTTP here.
Is there any *real* reason to do that? Even archweb doesn't do that and I don't understand the concerns here. Every half-attentive should be perfectly fine with how we do it in current master. And in case you're really, really paranoid, just setup a proxy that blocks HTTP connections to the AUR.
If I recall correctly some time after that debate/argument there was a problem with certificates and wget - a problem that was supposedly impossible. Anyways, the redirect is Really God Damned Annoying. If I ask for HTTP please give me HTTP. If I ask for ssl on top give me that. Please don't employ hacky rules in the web server config. That redirect is subject to a MITM attack just as well. A user might not even notice that they've been redirected to another site. If you really want to promote security don't even respond to requests on port 80. I agree that encryption should be recommended, but not forced.
On Fri, 5 Aug 2011 19:22:21 -0400, Loui Chang wrote:
If I recall correctly some time after that debate/argument there was a problem with certificates and wget
Wget was broken, yes. But this is fixed by now.
- a problem that was supposedly impossible. Anyways, the redirect is Really God Damned Annoying. If I ask for HTTP please give me HTTP. If I ask for ssl on top give me that. Please don't employ hacky rules in the web server config.
That is a strange argument. First of all why would you explicitly decide against encryption? And more important: Most users don't decide using to HTTP. This decision is made by links theyy click or their browser when typing in the URL directly.
That redirect is subject to a MITM attack just as well. A user might not even notice that they've been redirected to another site. If you really want to promote security don't even respond to requests on port 80.
This argument is hard to follow. So you say using no encryption will lower the chance of mtm attacks? Not responding on port 80 is a bad idea as browser will try this port first and there are a lot of old links around.
I agree that encryption should be recommended, but not forced.
Maybe forcing is a bad word here. Its more about ensuring security. ATM http is recommend and I bet most users use the AUR unencrypted atm. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat 06 Aug 2011 11:21 +0200, Pierre Schmitz wrote:
On Fri, 5 Aug 2011 19:22:21 -0400, Loui Chang wrote:
If I recall correctly some time after that debate/argument there was a problem with certificates and wget
Wget was broken, yes. But this is fixed by now.
- a problem that was supposedly impossible. Anyways, the redirect is Really God Damned Annoying. If I ask for HTTP please give me HTTP. If I ask for ssl on top give me that. Please don't employ hacky rules in the web server config.
That is a strange argument. First of all why would you explicitly decide against encryption? And more important: Most users don't decide using to HTTP. This decision is made by links theyy click or their browser when typing in the URL directly.
Right. Let me make that decision myself. Thanks. I would decide against encryption if I have problems with ssl so that I can just go ahead and retrieve the PKGBUILDs that I need to do my job. I manually review their authenticity anyhow.
That redirect is subject to a MITM attack just as well. A user might not even notice that they've been redirected to another site. If you really want to promote security don't even respond to requests on port 80.
This argument is hard to follow. So you say using no encryption will lower the chance of mtm attacks? Not responding on port 80 is a bad idea as browser will try this port first and there are a lot of old links around.
Users may get a false sense of security with the redirect. I'm saying that having that redirect doesn't change the chance of mitm attacks. An attacker will impersonate the Arch server from the http onward and all your ssl is for nothing. If you're worried about old links then you can serve a page saying that http is no longer supported, so people can figure out what's going on. Increased security usually involves some discomfort.
I agree that encryption should be recommended, but not forced.
Maybe forcing is a bad word here. Its more about ensuring security. ATM http is recommend and I bet most users use the AUR unencrypted atm.
Yeah the links just need to be updated to recommend ssl.
On Sat, Aug 06, 2011 at 11:21:47AM +0200, Pierre Schmitz wrote:
On Fri, 5 Aug 2011 19:22:21 -0400, Loui Chang wrote:
If I recall correctly some time after that debate/argument there was a problem with certificates and wget
Wget was broken, yes. But this is fixed by now.
- a problem that was supposedly impossible. Anyways, the redirect is Really God Damned Annoying. If I ask for HTTP please give me HTTP. If I ask for ssl on top give me that. Please don't employ hacky rules in the web server config.
That is a strange argument. First of all why would you explicitly decide against encryption? And more important: Most users don't decide using to HTTP. This decision is made by links theyy click or their browser when typing in the URL directly.
* Because there might be sucky applications on crappy embedded devices that do not support HTTPs (although I doubt there's actually a lot of these). * Because there's some overhead. * I know these aren't strong arguments, but even having no real reason against encryption doesn't mean that we should disable HTTP if there's no real objection against using HTTP with reason as well.
That redirect is subject to a MITM attack just as well. A user might not even notice that they've been redirected to another site. If you really want to promote security don't even respond to requests on port 80.
This argument is hard to follow. So you say using no encryption will lower the chance of mtm attacks? Not responding on port 80 is a bad idea as browser will try this port first and there are a lot of old links around.
I agree that encryption should be recommended, but not forced.
Maybe forcing is a bad word here. Its more about ensuring security. ATM http is recommend and I bet most users use the AUR unencrypted atm.
We already discussed that this will change.
On Sat, 6 Aug 2011 12:26:53 +0200, Lukas Fleischer wrote:
* Because there might be sucky applications on crappy embedded devices that do not support HTTPs (although I doubt there's actually a lot of these).
OK, let's say this is not a valid argument.
* Because there's some overhead.
For our site this would be barely measurable and definitely not noticeable.
* I know these aren't strong arguments, but even having no real reason against encryption doesn't mean that we should disable HTTP if there's no real objection against using HTTP with reason as well.
There are quite a lot of reasons for using https. And even unsure, one should prefer https as it improves security in some cases and in worst case wont have any real downside. I have found some other article (including nmore links) which might be interesting to read: https://www.eff.org/pages/how-deploy-https-correctly -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this: 1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted. 2) Ensure that the cookie is never sent over http, only over https. Everything less than that is completely irresponsible.
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
On Sat, 6 Aug 2011 13:13:06 +0200, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
That was one of my arguments: Using https everywhere is plain simple to implement and you don't have to worry about any holes in your implementation; e.g. if you forgot to secure on form.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
-- Pierre Schmitz, https://users.archlinux.de/~pierre
On 06.08.2011 13:13, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
Securing the login page itself is quite good and prevents eavesdropping, but it doesn't take care of MITM attacks. If Alice is on http://aur.archlinux.org and clicks on a login link that points to http://aur.archlinux.mallory.com/login.php the browser won't complain about anything and Mallory can easily get access to her password. -- Florian Pritz
On Sat 06 Aug 2011 13:25 +0200, Florian Pritz wrote:
On 06.08.2011 13:13, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
Securing the login page itself is quite good and prevents eavesdropping, but it doesn't take care of MITM attacks.
If Alice is on http://aur.archlinux.org and clicks on a login link that points to http://aur.archlinux.mallory.com/login.php the browser won't complain about anything and Mallory can easily get access to her password.
This is why the redirects are also a charade. If Bob requests http://aur.archlinux.org but is redirected to http://aur.archlinux.frank.org rather than https://aur.archlinux.org he is probably expecting http anyways and may not bat an eye.
On Sat, 6 Aug 2011 04:30:09 -0400, Loui Chang wrote:
This is why the redirects are also a charade. If Bob requests http://aur.archlinux.org but is redirected to http://aur.archlinux.frank.org rather than https://aur.archlinux.org he is probably expecting http anyways and may not bat an eye.
HSTS tries to address this issue. At least regular users will be secured by using this. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, Aug 06, 2011 at 01:40:38PM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 04:30:09 -0400, Loui Chang wrote:
This is why the redirects are also a charade. If Bob requests http://aur.archlinux.org but is redirected to http://aur.archlinux.frank.org rather than https://aur.archlinux.org he is probably expecting http anyways and may not bat an eye.
HSTS tries to address this issue. At least regular users will be secured by using this.
That is crap. HSTS alone won't fix this at all. If the response to the first HTTP request is already injected, the browser won't even see the HSTS headers at all. As a said before, the certificate itself is the only feature that allows for checking authenticity here.
On Sat, 6 Aug 2011 14:07:34 +0200, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:40:38PM +0200, Pierre Schmitz wrote:
On Sat, 6 Aug 2011 04:30:09 -0400, Loui Chang wrote:
This is why the redirects are also a charade. If Bob requests http://aur.archlinux.org but is redirected to http://aur.archlinux.frank.org rather than https://aur.archlinux.org he is probably expecting http anyways and may not bat an eye.
HSTS tries to address this issue. At least regular users will be secured by using this.
That is crap. HSTS alone won't fix this at all. If the response to the first HTTP request is already injected, the browser won't even see the HSTS headers at all. As a said before, the certificate itself is the only feature that allows for checking authenticity here.
Neither I nor the HSTS website tells you that this is about securing the first http request. That's why I said this will only secure regular users. Also you should note that this is only a small step to make things a little more secure. Anyway; this is going nowhere. So if the TUs and AUR users prefer less security somehow there is not much I can do about it. All arguments haven been described so now it's up to you to decide whether to ignore them or not. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, Aug 06, 2011 at 01:25:05PM +0200, Florian Pritz wrote:
On 06.08.2011 13:13, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
Securing the login page itself is quite good and prevents eavesdropping, but it doesn't take care of MITM attacks.
If Alice is on http://aur.archlinux.org and clicks on a login link that points to http://aur.archlinux.mallory.com/login.php the browser won't complain about anything and Mallory can easily get access to her password.
Mallory could do that whenever he wants to. Even if we use HTTPs for the whole AUR, there could be a MITM attack when the user requests http://archlinux.org/. The only thing that fixes that properly is the SSL certificate itself (and probably only a EV-SSL certificate will make this really easily recognisable).
On 06.08.2011 13:43, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:25:05PM +0200, Florian Pritz wrote:
On 06.08.2011 13:13, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
Securing the login page itself is quite good and prevents eavesdropping, but it doesn't take care of MITM attacks.
If Alice is on http://aur.archlinux.org and clicks on a login link that points to http://aur.archlinux.mallory.com/login.php the browser won't complain about anything and Mallory can easily get access to her password.
Mallory could do that whenever he wants to. Even if we use HTTPs for the whole AUR, there could be a MITM attack when the user requests http://archlinux.org/. The only thing that fixes that properly is the SSL certificate itself (and probably only a EV-SSL certificate will make this really easily recognisable).
Unfortunately that doesn't add any security. http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Effectiveness_a... -- Florian Pritz
On Sat, Aug 06, 2011 at 02:15:43PM +0200, Florian Pritz wrote:
On 06.08.2011 13:43, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:25:05PM +0200, Florian Pritz wrote:
On 06.08.2011 13:13, Lukas Fleischer wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
2) Ensure that the cookie is never sent over http, only over https.
We discussed that before, see the other replies. This will be implemented.
Securing the login page itself is quite good and prevents eavesdropping, but it doesn't take care of MITM attacks.
If Alice is on http://aur.archlinux.org and clicks on a login link that points to http://aur.archlinux.mallory.com/login.php the browser won't complain about anything and Mallory can easily get access to her password.
Mallory could do that whenever he wants to. Even if we use HTTPs for the whole AUR, there could be a MITM attack when the user requests http://archlinux.org/. The only thing that fixes that properly is the SSL certificate itself (and probably only a EV-SSL certificate will make this really easily recognisable).
Unfortunately that doesn't add any security.
http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Effectiveness_a...
Dude, that paper talks about people with "no training in browser security features". That's people who know nothing about SSL certificates and cannot even distinguish between the blue and the green mark that Firefox shows beside the address bar. I doubt this is our target group. Please don't just paste anything you picked up anywhere.
Am 06.08.2011 13:13, schrieb Lukas Fleischer:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier.
Then at least hardcode https for the login form, so the password is always sent securely. This will still have the problems Florian mentioned, but it is better than nothing. Alternatively: Do not display a login form on http, instead display a link "If you want to login, switch to a secure connection first.". This way, the user verifies the certificate and URL first (by looking at the URL bar), then enters his password.
On Sat 06 Aug 2011 13:39 +0200, Thomas Bächler wrote:
Alternatively: Do not display a login form on http, instead display a link "If you want to login, switch to a secure connection first.". This way, the user verifies the certificate and URL first (by looking at the URL bar), then enters his password.
I agree with this. As long as the rest of the site is functional via http.
Am 06.08.2011 10:52, schrieb Loui Chang:
On Sat 06 Aug 2011 13:39 +0200, Thomas Bächler wrote:
Alternatively: Do not display a login form on http, instead display a link "If you want to login, switch to a secure connection first.". This way, the user verifies the certificate and URL first (by looking at the URL bar), then enters his password.
I agree with this. As long as the rest of the site is functional via http.
This is a solution I can live with, too.
On Sat, Aug 6, 2011 at 1:13 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Sat, Aug 06, 2011 at 01:02:03PM +0200, Thomas Bächler wrote:
Am 05.08.2011 23:54, schrieb Lukas Fleischer:
[1] http://projects.archlinux.org/aur.git/commit/?id=1e7b9d57 [2] http://projects.archlinux.org/aur.git/commit/?id=5ea9fc19 [3] http://projects.archlinux.org/aur.git/commit/?id=973e4f85 [4] http://projects.archlinux.org/aur.git/commit/?id=89721137
Those commits are nothing but a charade. The very least you must do is this:
1) ALWAYS force a redirect to https on the AUR login page, never allow the login to be submitted unencrypted.
Thought about that. The problem is that there currently isn't a separate login page. Maybe removing the overall login form and creating a separate page for that will make things easier. you can also use the https context exported from your web server.
if https => redirect 302 to https else login form. if($_SERVER['HTTPS'] != 'on'){ $url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; redirect($url); } -- Sébastien Luttringer www.seblu.net
For all tl;dr guys around. This is my proposal: * Use HTTPs links by default (this is already implemented). * Enable secure cookies. * Disallow HTTP login (or at least print a big, fat warning if a user tries to login via HTTP). * Possibly use HSTS. This should fix all possible vulnerabilities related to HTTPs we can actually fix. Let me know if I missed something.
Lukas Fleischer wrote:
For all tl;dr guys around. This is my proposal:
* Use HTTPs links by default (this is already implemented).
* Enable secure cookies.
* Disallow HTTP login (or at least print a big, fat warning if a user tries to login via HTTP).
* Possibly use HSTS.
This should fix all possible vulnerabilities related to HTTPs we can actually fix. Let me know if I missed something.
I've just read through all the threads but my reply is general so I'll post it here. First, I strongly support the use of methods and protocols that improve privacy and security and I very much appreciate Pierre's and everyone else's efforts here. Most of Lukas' proposal looks good to me. I propose that all requests from an external referrer be redirected to HTTPS to catch users clicking onto the AUR via search engines. You could make this clear via a redirection page that informs the user of the security benefits of using HTTPS. Users who still wish to access the AUR via plain HTTP can still type in the HTTP address once and then browse the site (but not log in) normally. As already discussed, it might not avoid all threats but it does avoid some, which is better than nothing, and blocking all HTTP would not be acceptable. You could also add a warning to HTTP pages to notify users that HTTPS is available and recommended (along with a link). Alternatively, you could just add a warning to HTTP requests with no referrer, i.e. requests typed directly into the address bar. Regards, Xyne
Am 06.08.2011 14:32, schrieb Lukas Fleischer:
For all tl;dr guys around. This is my proposal:
* Use HTTPs links by default (this is already implemented).
* Enable secure cookies.
* Disallow HTTP login (or at least print a big, fat warning if a user tries to login via HTTP).
I would really go with "disallow". Don't even show a login form, just a link that directs to https _before_ being able to enter a password.
* Possibly use HSTS.
This should fix all possible vulnerabilities related to HTTPs we can actually fix. Let me know if I missed something.
Yes, the list looks complete.
On Sun, Aug 07, 2011 at 11:31:58AM +0200, Thomas Bächler wrote:
Am 06.08.2011 14:32, schrieb Lukas Fleischer:
For all tl;dr guys around. This is my proposal:
* Use HTTPs links by default (this is already implemented).
* Enable secure cookies.
* Disallow HTTP login (or at least print a big, fat warning if a user tries to login via HTTP).
I would really go with "disallow". Don't even show a login form, just a link that directs to https _before_ being able to enter a password.
Yes, I will make this configurable (via "config.inc.php") but "disallow" will be the default value and the value used in the AUR setup on sigurd.
* Possibly use HSTS.
This should fix all possible vulnerabilities related to HTTPs we can actually fix. Let me know if I missed something.
Yes, the list looks complete.
Thanks for reviewing!
Also please ensure aur-notify mails for package comments provide https links. Regards. Keshav
On Tue, Aug 16, 2011 at 01:21:57PM +0530, KESHAV P.R. wrote:
Also please ensure aur-notify mails for package comments provide https links.
That has been implemented for a long time [1]. [1] http://projects.archlinux.org/aur.git/commit/?id=973e4f85
participants (19)
-
Baptiste
-
Cédric Girard
-
Estêvão
-
Florian Pritz
-
Gordon JC Pearce
-
Heiko Baums
-
Ionut Biru
-
Isaac Dupree
-
KESHAV P.R.
-
Loui Chang
-
Lukas Fleischer
-
Matej Ľach
-
Philipp Überbacher
-
Pierre Schmitz
-
rafael ff1
-
Ray Rashif
-
Seblu
-
Thomas Bächler
-
Xyne