Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
iPassword 8 - error signing in when using proxy
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
48 Replies
dteare1Password Team
That would explain it. Thanks for clearing that up.
++dave;
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
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 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.- 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
webpkito 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
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?
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)?
