iPassword 8 - error signing in when using proxy

MattW15

I have a required local proxy security software (including SSL) on some of my systems for work, I've found there seems to be a problem with version 8. I can't sign in, it just gives a sign-in error, but if I look in the logs I'm getting some kind of HTTP error. With an identical system version 7, even the betas, work perfectly.

I can't exclude applications from it but I can exclude URLs if necessary.

These are the relevent log entries - If I try multiple times they just repeat each attempt.

WARN 2021-11-16T09:32:02.737 tokio-runtime-worker(ThreadId(5)) [1P:op-db-queue\src\operations.rs:1195] operation transaction #tx#7(set_object_bytes) took more than 100 ms (128 ms)
INFO 2021-11-16T09:32:07.473 tokio-runtime-worker(ThreadId(8)) [1P:foundation\op-windows\src\windows\network\proxy.rs:127] network proxies discovered: 1
INFO 2021-11-16T09:32:07.923 tokio-runtime-worker(ThreadId(8)) [1P:foundation\op-windows\src\windows\network\proxy.rs:220] proxy connected successfully
INFO 2021-11-16T09:32:07.923 tokio-runtime-worker(ThreadId(3)) [1P:foundation\op-proxy\src\lib.rs:150] selected HTTP proxy to use
ERROR 2021-11-16T09:32:08.118 tokio-runtime-worker(ThreadId(5)) [1P:op-app\src\app\backend\signin.rs:304] error signing in from data layer: UnableToCreateClient(HttpError(IoError(IoError(error sending request))))
ERROR 2021-11-16T09:32:08.118 tokio-runtime-worker(ThreadId(5)) [1P:C:\builds\dev\core\core\op-signin\src\lib.rs:421] error signing in from data layer: other error
ERROR 2021-11-16T09:32:08.118 tokio-runtime-worker(ThreadId(5)) [1P:C:\builds\dev\core\core\op-ui\src\signin\handlers.rs:363] Error signing in: other error

---

1Password Version: 8.04 (from logs)
Extension Version: 2.1.4
OS Version: Windows 10 x64

trolli

+1

Cant login to 1Password. Always brings up the message "cant login to your account" (sorry, 1Password is in german).
Password for account is correct. Tried in Browser and works... (iOS also works).

Logs are empty after I cleaned them up, so dont know how to get the logs atm.

Jack.P_1P

Hi @MattW15 and @trolli:

Just to confirm are you both using security software that is doing some sort of TLS/SSL interception?

Jack

trolli

I know we have SSL inspection active.

MattW15

Yes, I do on my end as well.

trolli

But then also the browser should not work in my opinion ? Is it not the same in the backend ?

Jack.P_1P

Thanks for confirming @trolli.

At the moment, 1Password 8 doesn't support network environments where SSL/TLS inspection may occur as it can fail our verifications. We recommend for now to postpone any upgrade to 1Password 8 and stick with 1Password 7 until we add support for these networks.

Jack

ref: dev/core/core#7409

MattW15

If we wanted to use 8, are there any URLs we can exempt from inspection to make it work? I have the ability to bypass inspection for domains, but not applications.

Jack.P_1P

Hey @MattW15,

Thanks for following up. At this time, exemption of URLs would not get around this issue.

Jack

____

I just encountered this issue (company traffic goes through proxy for SSL interception with swapped SSL w/ root CA) and found this thread. My understanding is that 1P does not rely on SSL to keep the vault safe as it's end-to-end encryption? Or the login process still sends unencrypted (besides SSL) key/credential data directly via SSL?

And although I failed to login when going through company network in 1P8 Windows app, I was able to login via the Chrome Extension with the same network. Does that mean the extension does not check whether the SSL was tempered during the login? And does that mean I have to change my key and password because they were probably logged (also with my vault all together)?

jkane001

I'm having the same issue. Any thoughts on how long it would be before 1Password 8 supports network environments where SSL/TLS inspection is happening?

dteare

Hello everyone, 👋

I received a similar question on Twitter and went digging for help in our internal Slack to find the answer. @ag_Christian was kind enough to explain the details to me so I thought I'd pay it forward here for others curious about the change. Including my future self when I forget the specifics. 🙂

1Password 7 used the WinHTTP networking APIs which rely on the TLS stack provided by the OS by default. In 1Password 8 we do all of our networking in Rust and use webpki to verify TLS certificates currently. We have some internal discussions going on for how to have the best of both worlds and will report back here when it becomes possible to use 1Password 8 in these environments.

I was a bit confused on how it was possible TLS traffic could be intercepted without failing validation. If you're in a similar boat, I found Christian's explanation helpful:

These TLS interception methods work by inserting a trusted CA into the system’s CA root store that is owned/controlled by the software/hardware doing the inspection. So when something connects to an HTTPS domain and sees the MiTM certificate, Windows’ sees that certificate was issued by a CA it knows about and was configured to trust.

I’ve always been fascinated by SSL introspection and as a user I’d prefer things to break. I totally understand this is likely beyond most people's control though, so it will be great to get this working again in 1Password 8. It also makes me happy that we use SRP to establish a separate encrypted session of our own so those SSL interceptors aren't gonna see much when looking at our traffic. 🙂

++dave;

ref: dev/core/core#7409

Siimnet

Also got the SSL interception issue w/v.8.4 (hate our McaFee SSL gateway :| )

Siimnet

Funny enough v.8.4.0 works behind SSL gateway from macOS

Stefan_Schulte

Same issue for my company.
I get why it was released this way, but you probably should at least mention it in the blog post somewhere, so people don't waste their time finding this thread.
Or some known issues page.

andrij_hu

Nice to hear that you hate TLS interception, as we hate it. But you are presenting you'r software for enterprise-level, how it cold not work in enterprise networks? (as I understand, sniffing TSL, is a standard for enterprise)

dteare

I'm not sure if it can be called a "standard" but I agree it is quite popular in the enterprise. It's a limitation of the first release and we're working on getting it fixed up.

As for adding this to the blog post, I was already failing at cutting content from the post to get it under my (admittedly self-imposed) 5 minute read limit. I like the idea of a known issues page though. I had started drafting something similar for this forum but didn't get it over the finish line. I'll look at dusting that off this week.

Regarding 8.4 working behind an SSL gateway on macOS, that's surprising to hear, @Siimnet. It's the same Rust library underneath the covers so I'd expect both Windows and Mac to behave the same. Specifically, I'd expect them both to fail at the moment. Is it possible the SSL inspector has been configured to avoid Macs or something?

++dave;
1Password Founder

Siimnet

@dteare hm rethinking, maybe it's because Mac possible isn't controlled by our security dept. and thus not configured to go through the SSL GW...

dteare

That would explain it. Thanks for clearing that up.

++dave;

gbrandel

Thank you @dteare for the detailed explanation of what's happening here. I was excited to give the version 8 client a try today at work but immediately ran into this issue. (I should have done a quick read of the known issues.) I've rolled back to the version 7 client and that will work fine until the issue is resolved. Like so many others, my workplace implements https inspection. I do understand why some organizations feel compelled to do this type of inspection but I don't love the practice. Indeed, one of the endearing qualities/features of the 1Password security architecture is that the TLS layer, while nice to have where available (uncompromised), is not technically necessary for the security of the client/server communications. It is 1Password's incorporation of SRP that really makes 1Password special in the cloud-based password manager product space.

Thanks again for the update. Hopefully, the issue will be resolved soon-ish. I'm eager to try out the new Electron-ified UI for the Windows application.

Best,
GBR

dteare

Hello everyone, 👋

I wanted to give an update on the changes to make things work properly with TLS/SSL interception setups in enterprise networks. The code that enables this was just merged a few minutes ago and we published a new nightly release so y'all could give it a try and see if it works in your setup.

If you'd like to give this a try yourself please go to Settings > Advanced and change the release channel to NIGHTLY and update. You should see build #80500038 or higher in the Settings > About window. Please let us know how it turns out. 🤗

For full discourse, note that this is a nightly release so in general it's not tested nearly as much as our betas. You'll be using the same version as our team is using which can be a good thing but can also mean you get bugs we haven't found yet and will need to live with them until they get fixed (likely in the next nightly or two).

Cheers! 🍻

++dave;

MikeT

Hi folks,

Your security setup may actually block the updates from showing up. Please download the latest nightly from here: https://downloads.1password.com/win/1PasswordSetup-latest.NIGHTLY.exe

dteare

Ah! Great point, Mike. Thank you for clarifying. ❤️

++dave;

VCarmona

Hi,
This error may have a different origin, but in case it helps, I tried it in my work environment, and it didn't work for me, just like the production version.
Version 80500042 NIGHTLY running on Windows 7 x64 Enterprise SP1.
I have attached the three log files as a screenshot and the last log file as text.

1Password_r00002.log:
INFO 2021-12-09T08:14:14.315 ThreadId(7) [client:typescript] Client starting.
INFO 2021-12-09T08:14:14.360 tokio-runtime-worker(ThreadId(2)) [1P:native-messaging\op-native-core-integration\src\lib.rs:238] Mute native core integration is waiting for Shared Lock State to be enabled
INFO 2021-12-09T08:14:14.360 ThreadId(7) [1P:op-localization\src\lib.rs:185] system locale detected as 'es-ES'
INFO 2021-12-09T08:14:14.361 ThreadId(7) [1P:op-localization\src\lib.rs:211] selected translations for ES_ES based on detected locale es-ES
INFO 2021-12-09T08:14:14.361 ThreadId(7) [status:op-app\src\app.rs:306] App::new(1Password for Windows/80500042 (ES_ES), C:\Users\29159392s\AppData\Local\1Password\1password.sqlite)
INFO 2021-12-09T08:14:14.362 ThreadId(7) [1P:op-db\src\db.rs:94] Starting DB at version: 23
ERROR 2021-12-09T08:14:46.751 tokio-runtime-worker(ThreadId(5)) [1P:op-app\src\app\backend\updater.rs:177] AppUpdates(Http(IoError(IoError(error sending request))))

Best regards.

jkane001

Is this still just available in the nightly build, or is it live yet?

Jack.P_1P

Hi @jkane001:

The improved SSL/TLS interception support is now in the beta channel as well. If you're looking to download the beta directly, it can be obtained from this link: https://downloads.1password.com/win/1PasswordSetup-latest.BETA.exe

Let me know how that goes!

Jack

jkane001

Looks like it works! Thanks!

Jack.P_1P

Glad to hear that did it for you @jkane001! :smile:

MikeT

Hi @VCarmona,

Can you confirm that you're still having this issue with the latest nightly/beta builds, which is at 8.5.0-87?

If yes, can you email us your diagnostics report? Here's how:

1. Open 1Password and then its settings
2. Select the Advanced tab and select Send Diagnostics.

Attach the diagnostics to an email message addressed to support+windows@1password.com.

In your email, please also include:

• A link to this thread: https://1password.community/discussion/125015/ipassword-8-error-signing-in-when-using-proxy
• Your forum username: VCarmona

Please do not post your diagnostic report to the forum.

You'll get an email from our automatic reply from BitBot. It'll include a support ID, please include it in your next reply here, so we can look for the email.

VCarmona

Hi MikeT,
I sended diagnostic report but waiting for automatic reply from BitBot.
Thanks!

1P_Gem

Hi @VCarmona! Just to let you know, we've received your email and will continue the conversation over there :) ref: IAF-22913-952