On 10/27/2010 03:44 AM, Loui Chang wrote:

On Tue 26 Oct 2010 23:50 +0300, Ionuț Bîru wrote:

...

we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected.

Kudos for their maintainers for following the aur development

Hmm. How did you go about doing this? Can you make it possible to visit the site via normal http as well?

Thanks.

Thomas did the switch and he redirected http to https. Maybe he can make it better but for now, the only one that know how to configure lighttpd good enough is Pierre and he's lazy :D -- Ionuț

On 10/27/2010 05:49 AM, Justin Davis wrote:

On Tue, Oct 26, 2010 at 1:50 PM, Ionuț Bîru wrote:

...

Hi,

we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected.

Kudos for their maintainers for following the aur development

Hi I maintain clyde lately. I try to keep it working anyways. This mandatory switch to https breaks clyde's AUR support. Clyde's AUR support is the only reason to use it, really... it is an AUR helper after all. Forcing all traffic to https is not what I would call "default". Default would be cool but generally a default option is not the _only_ option.

Hi, i didn't know that there is another maintainer and i announced personally Digitalkiwi, for more than one month(i believe), that we are switching. He said that is working and it shouldn't be a problem.

I hadn't joined aur-dev. I am assuming the switch was announced there. I already am a part of this mailing list and most of what I receive from it is junk to me. I also joined the pacdev mailing list long ago but filtered that because it fills my mailbox with stuff I don't care about. All I care about are API changes to libalpm, really, and I usually just diff the sources to find them.

This switch was mostly discuss it in bugtracker

Out of curiosity I looked at slurpy on github and it hasn't been updated since July. Cower was updated 4 days ago. If an AUR helper uses a sufficiently high-level interface they won't need to update because they get forwarded to the HTTPS URI. Everything is automagically fixed for them. Clyde is probably the only AUR helper to suffer from this because of its low-level Luasocket library. Maybe paktahn as well. Kudos to falconindy at least for updating cower to use https by default.

That was mostly a rant by me side and is should be ignored :P

I'm glad that logins to the AUR are now encrypted. Previously they weren't which is always surprising to find out. Other than logins I could care less if my traffic is sniffed. I know the logic is easier to just switch _everything_ to HTTPS but could maybe we just use https for logins? Could you allow HTTPS to be optional (except for logins) and then give validity to the term "default"?

As i said earlier in a reply to Loui, maybe we can do it better.Having https only for login and then redirecting to http is like not having it at all. -- Ionuț

On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:

On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru wrote:

...

As i said earlier in a reply to Loui, maybe we can do it better.Having https only for login and then redirecting to http is like not having it at all.

Simply using https for all connections is the easiest and best solution imho. Everything in between is either insecure or inconvenient for the users. And I also don't see the need for it. Every sane http client should handle a http redirect and https. If it does not it's just a bug in the client. Of course it is unfortunate that this wasn't tested by the clyde author before.

I would appreciate if you consult aur-dev before making changes to the AUR. Can you please describe how you made this change, and how we can enable normal http?

On Thu 28 Oct 2010 18:01 +0300, Ionuț Bîru wrote:

On 10/28/2010 03:27 AM, Loui Chang wrote:

...

On Wed 27 Oct 2010 14:14 +0200, Pierre Schmitz wrote:

...

On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru wrote:

...

As i said earlier in a reply to Loui, maybe we can do it better.Having https only for login and then redirecting to http is like not having it at all.

Simply using https for all connections is the easiest and best solution imho. Everything in between is either insecure or inconvenient for the users. And I also don't see the need for it. Every sane http client should handle a http redirect and https. If it does not it's just a bug in the client. Of course it is unfortunate that this wasn't tested by the clyde author before.

I would appreciate if you consult aur-dev before making changes to the AUR. Can you please describe how you made this change, and how we can enable normal http?

seriously, why did you changed it back to http over https?

in less than 1 day all aur helpers are working again and i don't see a reason to use http again. Really, what's the point?

The AUR isn't yours alone to decide how everyone should use it. That's one reason you should consult aur-dev before making such changes. SSL will still work. The point is to allow users to make the choice whether or not they want to use ssl. That choice was impossible the way it was implemented.

I'm glad I sparked a discussion! I however am still on the decidedly non-paranoid side. Yes I know how man in the middle attacks work. Yes I understand it's possible. No I don't think it's likely. Basically because there is no money involved. Take that as naivete or ignorance if you want but I'm not jumping on the bandwagon. Everyone has taken a technical low-level look at the problem but my point of view is a little broader. The AUR security model is so weak as it is. Anyone can upload any package to run arbitrary code on your machine. Just slapping on https as if to say "we're secure now!" doesn't make me feel more secure. If someone wants to mess with me they don't have to hijack my connection they just upload a bad package. Just to be clear I think the freedom of allowing anyone to upload a package is a good thing and worth the security risk. I haven't been bitten by any malicious packages so far though I usually check them. HTTPS is great, feel free to use it. Switching it to mandatory and telling me how much better off I am seems a bit like evangelism. I don't think HTTPS is bad I just think forcing everything to HTTPS is a lazier than fixing the login to use HTTPS. Yes people can sniff my session id to just about any site I visit. Session IDs change. Sniffing a password is much more dangerous. Passwords are personal property. Passwords can be reused... like on other ArchLinux sites. -- -Justin

On 10/30/2010 04:42 AM, Philipp Überbacher wrote:

Excerpts from Justin Davis's message of 2010-10-29 20:25:26 +0200:

...

I'm glad I sparked a discussion!

I however am still on the decidedly non-paranoid side. Yes I know how man in the middle attacks work. Yes I understand it's possible. No I don't think it's likely. Basically because there is no money involved. Take that as naivete or ignorance if you want but I'm not jumping on the bandwagon.

Everyone has taken a technical low-level look at the problem but my point of view is a little broader. The AUR security model is so weak as it is. Anyone can upload any package to run arbitrary code on your machine. Just slapping on https as if to say "we're secure now!" doesn't make me feel more secure. If someone wants to mess with me they don't have to hijack my connection they just upload a bad package.

Just to be clear I think the freedom of allowing anyone to upload a package is a good thing and worth the security risk. I haven't been bitten by any malicious packages so far though I usually check them. HTTPS is great, feel free to use it. Switching it to mandatory and telling me how much better off I am seems a bit like evangelism.

I don't think HTTPS is bad I just think forcing everything to HTTPS is a lazier than fixing the login to use HTTPS. Yes people can sniff my session id to just about any site I visit. Session IDs change. Sniffing a password is much more dangerous. Passwords are personal property. Passwords can be reused... like on other ArchLinux sites. Often enough, and AUR is an example, it's sufficient to be logged in to change the current password. Knowing the session ID is thus almost equivalent to knowing the password.

Yes, but one thing keeps coming up in my mind: how many people would actually DO this? It isn't like the AUR is that big a target, most PKGBUILDs aren't that big a target and I doubt a hacker would go out of their way to track one of the maintainers, wait for them to go to a public network, then get their session id. If it were one of the binary repos, I'd understand, but at this point it just seems like Fear, Uncertainty, and Doubt have visited once again. Smartboy

On Sat, Oct 30, 2010 at 02:30:58PM +0200, Philipp Überbacher wrote:

Now that you say maintainers, I wonder how the system works for TUs, since they do upload binary packages. Is there a single sign-on or something like this?

We upload packages using devtools and SSH (scp(1)) - the same way the devs are doing it. And there is the archweb interface for handling orphaning/adopotion and stuff. It uses SSL, by the way :p

On Sat, Oct 30, 2010 at 08:47:59AM -0700, Justin Davis wrote:

If the password is used in more than one place and sniffed out, then not only is the user's AUR account compromised but also other accounts on other websites. It is easier to run a sniffing program that are already setup to search POST form data for the parameter name "password" (or something similar) instead of targeting the AUR specifically and looking for the "AURSID" cookie.

If the password is the same for the user's email account, the hacker just has to look the email up on the AUR and go from there. They can also cross-reference the email to other accounts.

This is one reason to never ever use a password twice.

On Sat, 30 Oct 2010 18:01:19 +0200 Philipp Überbacher wrote:

It's funny that even on this technical list the term hacker is used :)

Really? It made me cry. However this whole thread is far beyond the border of our beloved state of "useful". This was a short determination between louipc and wonder, the rest of it just pure "bla bla". Now both types of building up a connection are possible, so we don't have to worry and if people are ever whining about stolen accounts it's their own problem. Now let this thread die. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

Ionut, This is a ridiculous claim. Maybe we should tell that to amazon, newegg, and oh I don't know... 99% of websites on the planet? Most sites use https only for logins and transactions. Publicly available information like aur comments, aur packages, images, etc don't really need encryption. Just about everything sent to/from the AUR is not sensitive information. Except login passwords. I would be pissed off if amazon had the same point of view. What if amazon decided that their https for logins and credit cards was the same as not having it at all and removed it?

...

Simply using https for all connections is the easiest and best solution imho. Everything in between is either insecure or inconvenient for the users. And I also don't see the need for it. Every sane http client should handle a http redirect and https. If it does not it's just a bug in the client. Of course it is unfortunate that this wasn't tested by the clyde author before.

Pierre, How is sending publicly available information unencrypted insecure? It does not warrant a need for additional security in the first place. If someone wants to see what comments you post on a package they go look at the package's page. They don't have to sniff your traffic. I am secure in my AUR traffic's triviality.

How is https for logins inconvenient for users? Forwarding between http and https happens transparently on every major website. Most people wouldn't know it was happening if it wasn't for the padlock graphic. Many still don't.

True story; and a lot of server resources would be saved by not having to encrypt information that doesn't need to be encrypted. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On 10/28/10 02:59, Justin Davis wrote:

Pierre, How is sending publicly available information unencrypted insecure?

Some (weak) arguments: 1. net infrastructure in between me and Arch-server can see which specific pages on aur.archlinux.org that I'm loading. And even change data such as PKGBUILDs maliciously, in theory. 2. in places with unencrypted/unencryptable wifi (like my college, for some reason..) my physical neighbors can spy on that information too. 3. "all https" reduces the chances of the website having bugs (security flaws) where it leaves the wrong things unencrypted... and if it has those bugs, it's not like we would notice, because it only affects people who are going out of their way to try and get other people's info. (It's good for a website to have option of all-https though. So the paranoid among us can use it. Related work: https://www.eff.org/https-everywhere Recent hype: http://codebutler.com/firesheep (about insecurity of logins that persist by means of unencrypted cookie -- I'm not sure, does this affect a partly-http AUR too, if you're logged in?)) -Isaac

On Thu, 28 Oct 2010 15:42:31 +0800, Gergely Imreh wrote:

On 28 October 2010 14:59, Justin Davis wrote:

...

Pierre, How is sending publicly available information unencrypted insecure? It does not warrant a need for additional security in the first place. If someone wants to see what comments you post on a package they go look at the package's page. They don't have to sniff your traffic. I am secure in my AUR traffic's triviality.

Please correct me if I'm wrong, it's not just about sniffing, it's about hijacking your session. Eg. one could record your logging in, then come back later, and orphan your packages (a "better" bad case), or update it with malicious code (a worse one) while it looks like it was you.... Not saying one would do that, but if we are throwing around hypotheticals...

Cheers, Greg

Yes, https is not only about preventing others from reading the transmitted data. It's also about making sure data was sent from the correct server and hasn't been altered. E.g. nobody has injected some code. Only encrypting the login page does not help much. The session itself has to be send unencrypted and can be hijacked. Only encrypting when one is login makes it unconvinced for users as they always would have add the s to http (or click a link) if visiting a link etc.. As for the server load: that's not true these days. There are some studies from Google when they switched to https and also from my own experience the increased load is not that significant to argue about. In general I think it's a good idea that we now use https for most sites and we shouldn't discuss about if that is sane or not but why are some clients unable to handle it. -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Thu, 28 Oct 2010 15:42:31 +0800, Gergely Imreh wrote:

On 28 October 2010 14:59, Justin Davis wrote:

...

On Wed, Oct 27, 2010 at 5:14 AM, Pierre Schmitz wrote:

...

On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru wrote:

...

...

As i said earlier in a reply to Loui, maybe we can do it better.Having https only for login and then redirecting to http is like not having it at all.

Ionut, This is a ridiculous claim. Maybe we should tell that to amazon, newegg, and oh I don't know... 99% of websites on the planet? Most sites use https only for logins and transactions. Publicly available information like aur comments, aur packages, images, etc don't really need encryption. Just about everything sent to/from the AUR is not sensitive information. Except login passwords. I would be pissed off if amazon had the same point of view. What if amazon decided that their https for logins and credit cards was the same as not having it at all and removed it?

As the discussion gets more technical, it is good to see what the people who actually know all about these issues have to say. I think it is very education (well, for me at least) to read Firesheep's author's comment on the people's reactions, and how there are many bad solutions that look like good ones. Eg. the "Why is it hard to stay safe - Forced SSL/HTTPS for posting of Login/Password credentials only" section. http://codebutler.com/firesheep-a-day-later

Re: Amazon and others, just because the big guys do it, does not mean they do it right.

...

...

Simply using https for all connections is the easiest and best solution imho. Everything in between is either insecure or inconvenient for the users. And I also don't see the need for it. Every sane http client should handle a http redirect and https. If it does not it's just a bug in the client. Of course it is unfortunate that this wasn't tested by the clyde author before.

Pierre, How is sending publicly available information unencrypted insecure? It does not warrant a need for additional security in the first place. If someone wants to see what comments you post on a package they go look at the package's page. They don't have to sniff your traffic. I am secure in my AUR traffic's triviality.

Please correct me if I'm wrong, it's not just about sniffing, it's about hijacking your session. Eg. one could record your logging in, then come back later, and orphan your packages (a "better" bad case), or update it with malicious code (a worse one) while it looks like it was you.... Not saying one would do that, but if we are throwing around hypotheticals...

Cheers, Greg

I am sitting in a (switched) network with over 1000 clients day for day. I really like the idea of having full-forced-TLS-encryption on websites. It is the only save way I can be sure that noone is sniffing my traffic with a simple arp-spoof. I don't care that other people know what sites I visit (I have a Facebook account and use the "Like" buttons, that says all) but I care that there could be someone in this building who has control over my traffic (whatever his reason may be). Therefore I agree to Greg's statement above and stronly disagree to Justin's. It is not about getting information that is public none the less. It is simply not the right way to get it and should be prevented. One user +1 from me for https-only on all Arch websites (in the hope the servers can handle that). -- Malte Rabenseifner, Germany mail@malte-rabenseifner.de -- Beneath knowing, understanding. Beneath understanding, seeing. Beneath seeing, recognizing. Beneath recognizing, knowing. --