1PW 7.0.532 uses unsecured connections to connect to AWS (Rich Icons download)
Hi,
it seems that 1PW 7 currently uses unsecured connections to connect to different instances of
ec2-52-XX-XX-XXX.compute-1.amazonaws.com
as well as
205.234.175.175
secured connections are:
52.222.171.214
server-52-222-171-14.fra54.r.cloudfront.net
My guess was, that the version checking is without encrypted transport layer (because I don't have a 1PW subscription). But it seems that this is over 443. It only happens when the app is started, so it could be telemetry. And as these can be extensive, I don't feel comfy either.
Would you care to explain what communication (besides 1PW Accounts) has TLS and what not, maybe why there's a differentiation and why not everything is encrypted over TLS?
Best,
Damnatus
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@Damnatus thanks for sharing your concerns. It's attempt to download rich icons from http://cache.agilebits.com, that usually starts shortly after items are loaded. Version checking is https://c.1password.com/dist/1P/win6/updates.json. Crash reporting is a post to https://b.1password.com. Subscription services are done via https://account-name.1password.com.
Update: watchtower is using https://c.1password.com.
0 -
Thanks @SergeyTheAgile ! :chuffed:
I forgot about rich icon download. Oops.
Subsequent question: As the information is sent unsecured could it be vulnerable to information disclosure on saved sites?
As stated here and here you don't log the requests. I have found here something from your dearest Chief Defender Against the Dark Arts about the information send to you. For me it seems, that it is possible to obtain these info and make a profile.
But I'm also no expert, just an enthusiast. So I may have overlooked something.Best,
Damnatus0 -
Hi @Damnatus,
This is a confirmed bug in 1Password 7 betas, we do use secure HTTPS for Rich Icons but we ran into a problem with updating 1Password 7 to use the updated
https://c.1Password.comURL scheme, so when we switched back to what we had before, it enteredhttp://instead ofhttps://.This will be fixed very soon.
Subsequent question: As the information is sent unsecured could it be vulnerable to information disclosure on saved sites?
I'm not sure I understand the question. If someone figured out your traffic like this, they would already have enough information from your normal browser sessions. Just visiting to reply on this forum would let the attacker know you're visiting
discussions.agilebits.com,https/httpdoesn't change this. Sending the URL insecurely like this does not give them more information, it does not confirm anything about your 1Password database, only that you have an existing item for a specific site. They cannot figure out your username/password or anything like that.For me it seems, that it is possible to obtain these info and make a profile.
It's already too late and without involving 1Password here. Your internet service provider and/or the sites you visit already does this, they have a log of all of your internet activities and many sites like Facebook logs your activities and they
may or may notresell these data for profit. There are services that buy these data from various endpoints and compile them into a unified profile on you to resell for higher profits. It is far easier to get the profile elsewhere than from 1Password.AgileBits does not treat you as a product but actual customers that do valve their privacy and security, which we take to be a critical part of our service to you.
0 -
Hi @MikeT ,
thanks for the extensive reply!It's true, that if someone could sniff my specific connections, they would have enough information.
What I have thought of was for example, that connections to
https://c.1Password.comcould be observed at one point in the routing by a man-in-the-middle (e.g. through re-routing like it happend end 2017 ). As far as I understand TLS (which is rather limited), encrypted traffic would be hard to read, but not so simple http.But I guess, that even if unlegitimized re-routing or some kind of other man-in-the-middle (besides the potential ISP) would be the case, the information obtained about the content to
https://c.1Password.com(the list with site-adresses without further details), could be linked to an IP (if it doesn't change over time which could happen with IPv6), but not to a computer/person. Right?I know that this is a speculative attack vector which needs a lot of effort and ressources, but targeting a sensitive data cloud storage might be considered worth it. But in THAT case, the icon cache is probably one of the smaller issues.
Sorry, I got sidetracked a bit. I just wanted to explain where the consideration came from. :chuffed:
Best,
Damnatus0 -
@Damnatus: Yep. You're correct that HTTP is plaintext (unless the payload is encrypted) but HTTPS communications are encrypted, but the URL you're requesting is still known, just not what you're "saying" to that site. MIke's point was that there isn't sensitive information involved in icon requests, so with someone having the ability to redirect or read them the real concern would be that they could see all of the HTTP and HTTPS requests and know all of the sites you visit anyway. We agree that it's gross, but the good news is that knowing which website's icon you request doesn't tell an attacker anything else about you or your data. So they'd just know the URL and your IP address in that case. So this is one of those cases where we want the behaviour to be different based on principle rather than on real risks to privacy or security. Cheers! :)
0 -
On behalf of the team, you're welcome.
0
