EV SSL for my.1password.com
When it comes to securing my stuff, I'm trusting 1password via my.1password.com. Recently my work decided to implement a MITM proxy (they pushed certificates to everyone's computers). I came close to screwing everything up yesterday by logging into my.1password.com to retrieve a password via the work network (I caught myself and didn't). It would have been really annoying to have potentially compromised my security. Shouldn't my.1password.com implement EV SSL so that lock icon is nice and green? I don't pretend to really know what that means... (besides trusting green!). I would know whether or not to trust a network by simply looking at the lock icon.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: kb:undefined, kb-search:EV SSL
Comments
-
Hi @spcarr
Sorry for the delay in responding. As a newer member of our security team I wanted to have someone check over my response before I sent it. Unfortunately, everyone is super busy here :)
There are a couple of important points to note about EV certificates.
Your data is actually encrypted locally on your devices prior to sending to our servers. This means that even if someone were to intercept your SSL traffic they would only be getting encrypted data from our server or from your computer. While I wouldn't suggest that you simply be okay with this, it is one additional protection that you might not have been aware of. SSL is not encrypting your actual data, it's merely encrypting the communication between our server and your client apps. Your data is encrypted separately.
EV Certificates have their own pitfalls. Notably:
- They cannot support wildcards. Families and Teams (and technically so does our individual plan) all use wildcards on the .1password.com domain. When an account is created a user picks a domain, for individual plans we map things up using some unique subdomains in the background. This would prevent us from using a wildcard EV certificate since they don't support wildcard subdomains.
- EV certificates only add additional verification, not security. By that I mean the "EV" stands for Extended Validation. Where the entity who bought the cert is indeed the same entity that owns the domain. It's really nice information to have and some browsers, notably Chrome, do offer some extra features that could warn you further if things have been tampered with. But in all cases you can also simply click the "key" icon in your browser and confirm who the cert belongs to. I'm guessing you've done this.
I hope that helps explain things a little bit. It's possible a colleague of mine might chime in with more details but if you also have any other questions please don't hesitate to let me know and I'll do my best to get you answers :) Sorry again for the delay in responding, that's totally on me.
0 -
Thank you for the very detailed reply!
I think key to the answer is point number 2 where, even if you guys had EV certs, that still wouldn't allow me to access my.1password without interception. It would just be a better warning. And if you encrypt everything beyond SSL anyways, it should protect others who aren't checking certificates (I'll leave that to you guys to handle, though :) ).
To follow up more on the contents being encrypted beyond just using SSL: Is the login information also encrypted inside of the SSL message? Can my account id and master password be intercepted by my IT department? Even if you guys had magic there, I still don't think I will trust this particular computer/network but it would be nice to know (I think my only real recourse is to ask IT to whitelist my.1password.com and be vigilant checking certs...).
0 -
Hi @spcarr
My pleasure and happy to help :)
So this is an important note and maybe isn't clear to everyone but even on the website client we never send your Master Password or Account Key to our servers. What happens is you enter your login credentials in the page, but this is a local "app" in a sense. Think of it as running in your browser. It then starts a communication with our servers and requests the encrypted content from our servers, once it arrives in the browser we use your Master Password and Account key to decrypt the data, or encrypt if it's being sent to the server.
Your Master Password and Account Key never leave your devices. Therefore, it cannot be intercepted by a MITM attack, or, filtering software, as the case may be. Funny how those behave the same way ;)
I would still see if maybe you can get anything at .1password.com whitelisted. It's really more of a privacy thing and you're trying to be smart and safe and they should, I hope, try to respect that. They may not budge, but, I would hope there are certain instances where they try to do the right thing and that this would be one of them.
0 -
@spcarr: I also wanted to add that we actually get a lot of support requests because 1Password.com (and AgileBits.com) are so strict about security.
Many "security" suites nowadays do the self-signed, person-in-the-middle shenanigans you mentioned, and our servers will flat out reject the connection when this happens: they require support for current TLS standards and a direct end-to-end-encrypted connection. When this doesn't happen, people can't login to 1Password.com or even download the apps from us.
It isn't immediately obvious, but along with Kyle's points about not transmitting the Master Password and Account Key from your end, we're doing everything we can behind the scenes on our end to ensure that even if you make a "mistake", it isn't going to compromise you. We wouldn't accept any less ourselves. :)
0 -
This information has been great and has made me much more comfortable trying to get at my vault from this work/'secured' network. Thank you very much agkyle and brenty.
Update: I submitted a ticket with our IT team and they agreed to whitelist my.1password.com. This was a very amazing and unexpected result of that request. While I'm not comfortable disclosing the company, it is a larger one and so having this exception added is not to be taken lightly. With that exception, the certificate is no longer being reported as theirs, and I'm able to login and see my vault....mostly. The vault looks kind of ugly as only my.1password.com was whitelisted, not cache.agilebits.com nor a.1password.com, which both appear to be used:
Refused to load the image '?origurl=https%3A%2F%2Fa%2e1password%2eco…2fimages%2fpadlock<etc.etc.removed>' because it violates the following Content Security Policy directive: "img-src 'self' data: blob: https://cache.agilebits.com
https://a.1password.com
https://a.1password.com/".I guess my request has now been altered into: I'm surprised I got this far with my company, any chance icons could be loaded from my.1password.com. ;) Just food for thought for future releases I guess. I'm quite happy to just be able to access my vault securely at work now, even though it is a bit ugly.
0 -
I am not making any promises as this is the sort of thing that needs to be managed very carefully, but we are looking at using HPKP to our service, which should help detect most attacks of that nature.
0 -
@jpgoldberg could you fill me in with HPKP? And what it does exactly? And how it would work in 1Password?
0 -
@ntimo This page should give you a good overview: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
:)
As jpgoldberg mentioned we can't make any promises or offer any implementation specific details at this point as we simply aren't there yet.
Ben
0 -
I'm sorry to have been so terse in my response.
One of the jobs of the TLS server's public key is prove that it is that server. The public key is public, but there is a corresponding private key that is known only by the server.
Public Key Pinning means that the first time your browser connects to an HTTPS server it is told information about what public keys to expect on future connections. So this won't help if the MITM starts with the first time you connect. But it does help if someone tries a Man in the Middle (MitM) attack of the sort described after your browser has learned what keys to insist upon.
The problem is that there need to be backup public keys waiting in the wings that are already listed as acceptable if we ever need to revoke a key. So if we have to revoke a key, but that is the only key that your browser has been told it can accept, your browser will refuse to connect even if the new key is super green.
So HPKP offers some real defense against some MitM attacks, it needs to be administered very very carefully to avoid accidental lockout. There are technical approaches for managing the backup keys and the HPKP headers to reduce those risks, but it still means that we need to work out internal procedures for managing all of that to make sure that we would never be caught short a usable key.
0
