SSL/TLS Issues

admdly

I'm a little concerned about some of the configuration choices for the SSL/TLS setup on 1password.com. Namely that SSLv3 is still supported (why?) and that RC4 is still being used with some browsers.

I'm also curious as to why an EV certificate wasn't used (I'm aware it confers no extra transport security, but they are theoretically harder for an attacker to obtain) and why modern ciphers aren't used (ChaCha20-Poly1305, for example).

Is there any background or reason for these choices? Given the state of the older versions of SSL/TLS in paticular and the concerns around security in this area, some of the decisions seem rather perplexing.

roustem

Hi @admdly!

Thank you for checking the SSL settings. I was sure that we got them the way we wanted but I recently had to disable CloudFlare (some customers reported issues) and that might have caused configuration change. We'll get it fixed.

Re: EV certificate. We are working on obtaining one for a few subdomains. As you know, there are no wildcard EV certificates.

ntimo

@roustem why did you use cloudflare?

ntimo

@roustem oh and could you please specify that the "for a few subdomains" means?

agiletim

Hi @admdly !

That's an interesting question.
Funny enough, we don't have SSLv3 enabled, same with RC4.
May I ask where do you get this information from ?
Can you compare your results to any SSL scanner output like this one

For EV certificate:
I agree, it is harder to obtain and it doesn't add to transport security. And also it is not compatible with our URL schema:
"customer_name.1password.com"
Here is why: there is no way to purchase wildcard EV certificate on the market and it would be quite inefficient to issue separate certificates for each customer.

Hope this answers your question :chuffed:

Thank you for helping us being more secure !

admdly

@roustem thanks for the response and glad it'll be sorted. :)

@agiletim I used SSL Labs - see https://www.ssllabs.com/ssltest/analyze.html?d=1password.com

I'm aware that wildcard EV certificates aren't permitted, but there is the option of an EV multi-domain certificate using SANs. This would likely be more complex and require some form of automated regeneration to include new names, and it could leak customers URLs in the certificate itself, but it'd be possible. ;)

One option could be to allow clients to upload and use their own certificate for their sub domain or issue a certificate per sub domain, for example with Let's Encrypt.

Either way the fixes to improve security to the level of the domain you provided (start.1password.com) are likely sufficient for most, and the addition of certificate pining etc would be great.

roustem

@ntimo,

The EV certificates provide the same security level as any other certificate. The only difference is that it is much more expensive and requires additional paperwork to verify the identity (that's where we got stuck at the moment as we can't get seem to get a reply from Dun & Bradstreet).

SSL provides basic transport security but there were so many issues with it recently that we wanted to have something that is more secure. This is why 1Password for Teams has an additional transport security layer based on SRP. And, don't forget that all data sent over is already encrypted with your Master Password + Account Key. That gives us 3 layers of encryption during transport: Master Password + Account Key, SRP, SSL.

Having said that, enough people asked about EV certificate that it is would be easier to have one. We can do that for the known sub-domains like teams.1password.com and start.1password.com.

CloudFlare gives us a few great features — DDoS protection, HTTP/2, additional intrusion detection, etc.

agiletim

@admdly: Thanks for your suggestions !
Right now we use set of precautions and enforcement techniques to minimize risk of attacks. And there is always space for improvement :chuffed:

In the same time we're trying to make our solution less complicated and more transparent for our users. So architectural decisions are tough, we spend a lot of time discussing optimization of the process and security features. I can't say the schema you described will be bad for us, neither the opposite. It is one of the options :smile: .

about 1password.com: this is marketing page and we don't use any significant enforcement there, but your comment made me thinking about it ...

Thank you !

jpgoldberg

Thanks, @admdly!

At the risk of repeating what others have said, I'd like to try to sum things up. (Those who know me, know that "sum things up" means saying more than what I am actually summarizing.)

Individual team domains

TLS v1.2 only

Take a look at the report for an individual team site. In particular you can take a look at the report for goldmark.1password.com. (My family's team).

You will find that for individual teams, like goldmark.1password.com (this is what my family and I use) that we use TLS v1.2 only.

EV or no EV?

As @agiletim pointed out, we create a subdomain for each team, and so we use a wildcard certificate for these teams. Extended Validation is (correctly) not possible for wildcard certificates.

Keep in mind that EV certificates are only about what sorts of measures the issuer has taken to validate that if it has the name "agilebits.com" that it really belongs to us, AgileBits. It says nothing about the actual encryption or protocols used. Returning to the example of my family's 1Password Team, goldmark.1password.com, I as a customer in this case, do not wish to try to provide the documentation to a certificate authority to prove that I represent the Goldberg-Markóczy family which sometimes goes by the name "goldmark".

EV certificates are useful, but don't over estimate the additional security properties they provide. (Back in the very old days when SSL was new, all certificates required the paper work that EV certificates require today.) EV certificates say nothing about what kinds of encryption and protocols are used; they only speak to how the certificate was issued.

Beyond TLS

The secrecy and authenticity of your 1Password for Teams data transport uses additional security beyond TLS. As @roustem pointed out, we use SRP so that the client and the server mutually authenticate each other (without revealing any secrets in the process.) Additionally, all your data is encrypted before transmission with keys derived from your Master Password and Account Keys.

Non-team domains

We have different security requirements for domains like teams.1password.com that just contain publicly available information. Unlike the domains for individual teams, there is no login process, no customer data. It is just providing non-secret information and collects nothing from customers.

TLS 1.0–1.2

The strict requirements we use with TLS 1.2 and a very limited set of ciphersuits needed to actually attempt to even log into your team are not requirements we could impose for people just wishing to learn about teams. It would rule out some reasonable browsers that people use.

Returning to that Qualys report for an individual team, let's look at

That would simply be unacceptably restrictive for something like teams.1password.com, which doesn't host any secrets or customer data.

EV certificates

EV certificates are possible for these domains, and once we settle on exactly what each of our static-ish domains are (remember, we are still in Beta) we will look more closely at which ones it will be useful to have EV certificates for.

Cloudflare

Cloudflare provides some terrific defenses for us, as @Roustem mentioned. But it also adds a level of indirection in the TLS relationship between client and server. In a sense we have a security versus security trade off in our decision whether to use Cloudflare. It defends against some threats while exposing others. How we proceed with this depends on what sorts of threats we see and what alternative mitigations are available.

So there you have it. My "summary".

admdly

@jpgoldberg thanks for the detailed response. Mobile right now so I can't give a comprehensive response.

Just one point regarding EV certificates: I'm aware they don't confer any additional transport security. My use case here and where I perceive benefit is in aiding users in detecting any foul play. If, for example, you were to use an EV certificate, my browser would show the green bar with "AgileBits, Inc" prominently. When I login I can see this and confirm that I'm at the correct place.

Now, let's say I'm an attacker and I go out and buy lpassword.com. I can obtain a domain certificate with no problem at all; all I have to do is prove I own the domain. I can spoof the site and obtain the details of users who may not notice the difference between 1password.com and lpassword.com. What I can't (easily) spoof is the green bar and AgileBits, Inc in the browser.

Now you're only using a domain certificate, so users aren't going to see or expect any green bar or company name anyway. This makes my spoofing much easier and I'm likely to be much more successful as an attacker.

Now that said, I'm not an attacker and I don't have any plans to become one. :p But this is a real issue that would be great if it could be mitigated against.

roustem

@admdly, if you bought "Ipassword.com" then you could probably also get a green bar with "AgIIeBits, inc"?

admdly

@roustem possible, yes. However, it's significantly harder. It'd cost me $10 (at most) for the lpassword.com domain and a free Let's Encrypt certificate. I don't even really need to disclose any of my personal (well, accurate) information.

To get the green bar, I'd have to register the business name AglleBits, inc in a state and than pass rigorous tests for an EV certificate. During this process, I'm likely to have had to use some accurate personal information (a mailing address for one) to register the business and pass validation.

Realistically, an attacker is not going to go through the steps needed for the second case unless there is a high profile target. Even then, there's no guarantee that they'd pass validation and there's the potential that the attacker could be traced in this case.

(Of course we're ruling out state actors here simply because they'd just hijack the domain or break the certificate if they so wished.)

jpgoldberg

Thanks, @admdly.

A lot of people don't understand what an EV certificate is (and is not) good for. So forgive me for pointing out what you already knew. (Really, a lot of people do need to have it pointed out.)

Your point is perfectly correct. Other things being equal, it would be good to have EV certificates for each domain. That isn't something we can do at this point for individual team domains, and it is something that we'd like to get to for our more "static" domains.

And while I'm in the mood to talk about "some things we would like to get to" with respect to TLS, I should include key pinning. We've been looking closely at HPKP for the team domains certificates. This is something that needs to be done very very carefully (making sure that we pin "backup" or "replacement" keys from different CAs and such).

So, as you note, there are a number of things that we can still do to shore up defenses against phishing or TLS attacks. As you may have noticed our use of HSTS is one that is already in place, along with our insistence on TLS v1.2. But there is still room for more. And EV certificates fall into that category.

Cheers,

-j

martinsuchan

Hi, according to recent tests on SSLLabs the 1password backend does not have any server-side priority of cipher suites. It also offers some weaker and not exactly common cipher suites like 3DES or CAMELLIA. It also leads to A- rating.
https://dev.ssllabs.com/ssltest/analyze.html?d=1password.com
Do you plan to fix the backend to offer cipher suites in proper order and the strongest cipher suites only? Ideally AEAD+PFS suites at the top followed by PFS suites.
Thanks

ntimo

@martinsuchan you have to do the test for a subdomain of 1password.com because that links to the team servers

Ben

Hi @martinsuchan

Jeff addressed this concern above. As pointed out testing an actual team, vs an informational page, will provide better results.

Hope that helps!

Ben