Add long time duration HSTS as a requirement for wallets

[saivann]

As previously suggested, this pull request submits HSTS as a new requirement for listed wallets.

All wallets' developers/businesses which didn't have HSTS welcomed the new requirement, the only remaining wallets not supporting long duration HSTS are Xapo and Circle.

I have picked 180 days max-age as a minimum requirement (this is what Qualys are recommending) and only applied the requirement when it matters (executable code, authentication) to avoid unreasonable situations where blocking a website for not supporting HSTS may be counterproductive.

@wikichaves Please comment on this pull request if the required header has been added to your website so Xapo can remain listed after the requirement is merged.

In the absence of critical feedback, this pull request will be merged on January 24th.

[harding]

LGTM.

[ywecur]

@saivann How does this affect the circle entry? Do they need to update their site?

[saivann]

@ywecur I sent details to Circle by email already given that they apparently aren't on GitHub. Circle would need to change one HTTP header on their website to be listed after this pull request is merged. HSTS basically tells the browser to connect to the website only through secured HTTPS connection to protect against MITM attacks. If for any reason Circle think they should not enable HSTS but still wish to be added, I'll invite them to comment on this pull request.

[saivann]

Quick update on this pull request: Xapo just enabled HSTS, Circle still hasn't answered my previous emails, I tried to contact them again yesterday.

[wikichaves]

Thanks @saivann

[saivann]

Unfortunately, Circle didn't respond to my repeated emails and didn't enable long duration HSTS as of now. If someone is aware of an improvement in their HSTS policy in the future, please comment or open a pull request so Circle can be re-added.

[petertodd]

After the fact ACK, thanks!

FWIW They are also still not randomising the position of the change address, an ugly and completely needless privacy problem.

[Dave-Aiello]

Why are we worried about HSTS and potential MITM attacks when we're including services with full custodial control over users bitcoins in the "wallets" section?

[WilliamDunne]

Because now instead of trusting the provider, you've got to trust everyone between you and the provider also.

[saivann]

@petertodd Really? IIRC I got a different change address for every transaction the last time I tested it.

The good news is I just received an answer from Circle and they're apparently rolling out HSTS soon. This being said, it's unclear if they'll actually want to be re-listed, bitcoin.org being possibly not optimized for the same mainstream users they are targetting, at least to my understanding.

[Dave-Aiello]

All it took was a complete PR disaster on Reddit

[ghost]

@saivann
The problem is that they are always in the same position in the transaction.

[saivann]

@privacydestroyer Ah, thanks! I'll be careful to pay attention when re-testing other wallets in the future.

[dthakur]

For some wallets, the intermediaries/infrastructure may not allow setting HSTS headers.

<speculation>
Looks like Circle is using CloudFlare based on the frontend IPs. Some googling shows that the CloudFlare's 'Universal SSL' product may not support configuring HSTS headers.
</speculation>

Celery uses Google App Engine. Right now, Google App Engine does not allow setting HSTS headers.

[saivann]

@dthakur Seems like Google allows HSTS to be enabled for specific domains as a workaround until the issue is fixed; https://code.google.com/p/googleappengine/issues/detail?id=7427#c6 .

[dthakur]

@saivann Yup, I'm in touch with that individual regarding manually white-listing our domains. However, I don't yet have a resolution eta.

[saivann]

@dthakur FWIW, if this issue is unresolved and your wallet is being submitted for review at a later point, I think this would be worth discussing more and possibly adapting the requirements.

[saivann]

I had the confirmation that Circle are preferring to not be listed on bitcoin.org for now, on the basis that the website targets a different audience than what they're searching for.

[ywecur]

@saivann What does that mean?

Circle is a functioning wallet and to my knowledge bitcoin.org doesn't cater to some specific audience.

Bitcoin.org is supposed to present viable wallet options, removing a wallet due to a vague statement like that seems like the wrong call.

[saivann]

@ywecur Well it's their own request, I am also a little bit confused.

[Dave-Aiello]

@ywecur When a company makes an explicit statement requesting exclusion, I think that might override any external criteria you may think they meet.

[ywecur]

@tokendave Why?

The purpose of this site is to list viable wallets. If Circle is a viable and popular wallet I believe it behoves us to add it regardless of whether they deem it nessesary or not.

[ywecur]

@saivann I believe we should list Circle regardless for the reasons explained above, if they now meet the criteria.

[Dave-Aiello]

Implied criteria: If a 'wallet' service is maintained by a single entity, that entity must consent to being listed.

[gurnec]

@saivann Just to be clear, have the Circle folk specifically asked to be removed from the bitcoin.org (for the time being)?

@ywecur Assuming the answer is yes, are you advocating that they be listed despite their wishes to the contrary? It seems to me that such an action would only bring unwanted controversy....

[saivann]

@gurnec Yes, they explicitely asked to not be listed, I made them repeat it just to be sure :) I've exchanged a few more emails with them hopefully to understand a bit more, but so far it's their decision. I agree that listing a wallet against their wish isn't ideal (and Circle are not HSTS compliant as of now anyway).

[ywecur]

@gurnec I believe that bitcoin.org should be able to list wallets without being "censored".

All that is displayed is a link and a short description of their service, this should not require their permission.

I don't believe intentionally leaving out quality wallets is going to do new users or the community any service, and in the end the site does exist for the benefit of the community not Circle.

[gurnec]

the site [bitcoin.org] does exist for the benefit of the community not Circle.

@ywecur Although I respect your point of view, I must humbly disagree. I rather think that maintaining a good relationship with others (and having a reputation for doing so), such as with Circle who also has a vested interest in promoting Bitcoin, is more important. Not much more for me to say on the subject, it's just my 2¢...

[luke-jr]

If Circle wanted to, they could redirect/404 anyone who follows a link from bitcoin.org. Might as well be polite and not try if they don't want a link.

[gladys123]

It's not a surprise why certain wallets would tell you they'd rather not be listed on Bitcoin.org, and the reason is pretty simple - they don't want to be playing your little games.

You (and by that I mean everyone who discusses this so called 'criteria') are acting as armchair dictators attempting to create a walled garden (yes, this is what it is, there is no difference between this and iPhone app requirements, et al) of Bitcoin clients. You are acting like you have some sort of authority, and that is justified to some extent. What is not justified is threatening developers with removal, in a "conform to this or else" style.

You've done it with Electrum over a non-security issue, over what is purely a pet peeve of Luke-Jr with his interpretation of how he thinks Bitcoin should work (such as: transactions to certain addresses are blacklisted). It's not up to him to decide that embedding messages in the blockchain is bad, it's not up to you guys to decide or argue over arbitrarily made-up criteria. If something's possible to do in the core protocol, tough luck.

Back on topic, Circle doesn't want to play with your little games anymore. Their responses are basically giving you the finger. It's not up to you to create a walled garden of Bitcoin clients. It's not up to you to decide arbitrarily criteria. If you believe something is less secure than it should be, then add a notice. Or remove it if you want. Threatening developers / companies that they must conform to your frequently updated, fiat "rules" is just making you guys look like a bunch of children playing government.

Furthermore, I don't think you guys understand that the first point of contact with a major company is not a developer or engineer. If you call AT&T's call centers and yell "Add HSTS support or I won't mention you guys in my blog!", they'll just hang up on you (politely). I promise that your initial emails were ignored and were never passed to anyone who touches code -- that's standard. But that's irrelevant. Even if some security engineer saw your emails with your threats / demands, if I was them I'd just have told you to bugger off and not associate with us. Which is what Circle is doing.

Oh, and you're saying "not on github" as something that's negative. GitHub is not a holy grail of unicorns and poptarts. I refuse to host my open source projects on GitHub because they're closed soruce. I like FOSS, and I am not going to put my FOSS projects on a closed source SAAS platform. GitHub's vendor lock-in has sadly forced me to maintain accounts to communicate here, whereas traditionally this would have been done through a mailing list that anyone can join. Perhaps this example makes you realize your opinion is just an opinion, and your opinion is not necessarily right (nor do you have any authority to dictate that).

[Azulan]

The great thing about the internet is that you can link to whatever you want to.

[gabridome]

@gladys123 interesting position.
I am personally thankful if a group of experts review some of the best wallets based on security and independence criteria.
Is it bitcoin.org the right place in which a new user should finds this kind of reviews?
I don't know but in this moment I don't see why not. Better here than nowhere.

As far as the wrong addressing of the mail is concerned I think that Circle is not At&t and they still do pay attention to expert developers and to the community. I don't see an issue here ATM.

[saivann]

I would be more inclined to take these criticisms seriously if they came from wallet developers, not users interpreting their decisions. Most if not all developers have shown appreciation for this work, argumented when they thought it was worth, and had a responsible behavior, including Circle. So, as far as I am concerned, I consider @gladys123 comments mostly a non-issue.

My experience thus far is that developers who care about security are willing to hear and discuss about any issue. Additionally, the barrier of entry today remains very low for apps that can steal or lose peoples' money at the slightest mistake. Not having basic requirements is a non-starter.

[ghost]

@gladys123
I preferred it when you were pretending to not exist, TradeFortress.

Remember that you lost 4100 BTC when your web wallet inputs.io was compromised?

Having a curated list of wallet's shortfalls is a step towards preventing disasters like you from happening.

[fluffypony]

@dthakur

CloudFlare doesn't much care what headers you add. It'll pass the HSTS header just fine -

[ ric->core ]$ curl -I https://mymonero.com
HTTP/1.1 200 OK
Server: cloudflare-nginx
...
Strict-Transport-Security: max-age=31536000; includeSubdomains;

[harding]

@fluffypony that's useful information. Thanks!

[davout]

Maybe you can enlighten me on the point of your comment? I actually wish
I was irrelevant in that space. I don't know anyone who would like to do
this work, especially when receiving childish comments like yours. Not
something I'd expect from one founder of Paymium.

The point is that the PKI is completely broken and is completely useless for anything bitcoin-related.
You might as well require that anything listed on bitcoin.org (not that it is in any way relevant to bitcoin) be valid xHTML.

[saivann]

PKI is completely broken and is completely useless for anything bitcoin-related.

@davout This is a pretty bold statement. By your logic, there is zero benefit from using SSL when transfering sensitive data to a server? And more to the topic, no benefit either to make sure many browsers cannot fallback to plaintext HTTP with HSTS?

[MineForeman]

I would be more inclined to take these criticisms seriously if they came from wallet developers, not users interpreting their decisions. Most if not all developers have shown appreciation for this work, argumented when they thought it was worth, and had a responsible behavior, including Circle. So, as far as I am concerned, I consider @gladys123 comments mostly a non-issue.

What nonsense.

You're not going to take someone's view seriously because they are not a wallet developer?

Bitcoin.org is ment to be a repositiory of information and it looses value if we only keep information that is 'deemed good' by a select group of people who have a vested intrest in their own little bit of the world.

It would have been far better if we just put a tag under the Circle wallet as being non-HSTS to keep people informed and not ignorant.

[wbnns]

Just want to point out that every change that has ever been made to Bitcoin.org over the last year has been posted here first, and is always open for discussion, including disagreement. If there is a dissenting majority to a suggested change, it gets revised and resubmitted for additional discussion, and the process happens over and over again until it gets merged, or it doesn't.

I don't think anyone will say that the current wallet page is perfect, nor the scoring or inclusion criteria. There has been an open discussion on how this should be done on here, for well over a year.

Instead of attacking each other personally, how about just submitting a pull request or opening up an issue for what would be a better alternative? Then we can all follow the above process.

The majority of people that come to Bitcoin.org are not developers. The majority of the people that manage it are - so let's accept that we can do a better job and work together for the best solution to find the common ground in the middle.

I don't think anyone wants to be here arguing, right?

[saivann]

OK some quick update; apparently if some people really want to add Circle, the contacts I've talked to don't seem to have any serious issue either way. So I guess we can just move forward (and not assume Circle will take part in discussions). If someone has any question, you can contact Circle directly.

Meanwhile, Circle have been communicative and rolled out HSTS, so if someone wants to open a pull request to re-list Circle (maybe @ywecur?), you're welcome.

As a matter of keeping things simple in the future, I think re-listing a wallet should be reasonably straightforward once it's confirmed that a wallet meets requirements for which it was temporarily delisted.

[ywecur]

@saivann Sorry for my Git ignorance, but when I try to open the same pull request Github tells me that my Circle branch is identical to the current master branch. That cannot be the case can it?

[harding]

@ywecur I just looked at your repository on GitHub, and your circle branch is an ancestor of current bitcoin.org master. That's probably what GitHub is trying to tell you.

I think what you want to do is:

1. Make sure your circle branch is based off of bitcoin.org's master. If you have the bitcoin.org repository as a remote named upstream, you can run the following command: git branch --set-upstream-to=upstream/master circle (running this command is safe even if you're already based on bitcoin.org master)
2. Update your circle branch to master, which is probably as simple as typing git pull
3. Cherry pick your previous circle commits: git cherry-pick a365ad3174c073750c87ecb7bdee86b89802174f 26c220f7821c07c82b434e5b7c698709d065eca7 4fa4960fe5fc66012d426f34ae2a2ac81d84c46b
4. Optional, but highly appreciated: squash them into one commit: type git rebase -i and then (when the first editor window appears) edit lines 2 and 3 to start with s for squash. Save the file and in the second editor window, clean up the commit message as you think is appropriate.
5. Run git push the same way you normally do to push the circle branch to GitHub, and then open a pull request.

If you have problems with the instructions above, let me know and I'll be happy to open the pull request for you.

[ywecur]

@harding I currently only have access to a Chromebook so I would very much appreciate if you did it for me.

[harding]

@ywecur opened pull #732 to re-add Circle.com.