Error "net/http: TLS handshake timeout"

twx

Hey there,

I am using latest op in Version 0.5.4

When trying to signin i get an error:

#> ./op signin something.1password.com my@mail.com
Enter the Secret Key for my@mail.com at something.1password.com: XXX
Enter the password for my@mail.com at something.1password.com: XXX
[LOG] 2018/10/17 08:20:01 (ERROR) Get https://something.1password.com/api/v2/auth/my@mail.com/XXX/XXX: net/http: TLS handshake timeout

I'm using MacOS Mojave 10.14.2
I would assume is it something on my Mac as this timeout occurs on different Wifis or VPN.
Can you help me on this?

Thanks, Thomas

---

1Password Version: 7.2.2
Extension Version: Not Provided
OS Version: OS X 10.14.2
Sync Type: Not Provided

twx

Oh and

#> op update
[LOG] 2018/12/13 14:15:54 (ERROR) Get https://app-updates.agilebits.com/check/1/0/CLI/en/054001/: net/http: TLS handshake timeout

gives the same error :'(

AGAlumB

@twx: Hmm. Either something is really wrong on your machine...or you've got some software filtering the connection. Anything like TripMode, antivirus, firewall, etc?

cohix

Yeah, my best guess would be a proxy or something interfering with the connection :/

twx

Thanks for your replies. This is really weird.

I tried "curl"ing the url from the previous error: This works as expected (I think):

#> curl https://app-updates.agilebits.com/check/1/0/CLI/en/054001/
{"available":"0"}%

cohix

That does look correct. Are the op errors consistent, or intermittent?

twx

op always shows that errors. it never worked with any command :(

cohix

Are you able to login to your account in your web browser @twx ?

twx

Yes, everything else works.

• Browser login
• Browser plugin
• Local Client

I have no problems doing anything just this op command does not work.
Do I need some libraries on my machine for op to work?

AGAlumB

You shouldn't need anything special on macOS. It works out of the box for me. Have you tried using it without being connected to a VPN? 1Password has its own encryption in addition to TLS, so security won't be an issue. I'm wondering if something is being blocked by the VPN service.

twx

I have tried it from different networks: company network, home network, VPN. All show the same error. ¯_(ツ)_/¯
So I assumed its something on my machine - but what?

cohix

@twx This is bizarre. Let me do some more digging on my side to try and reproduce this.

twx

Thanks for taking care @cohix
I would love to play around with op and integration into our tools.
Your help is very much appreciated :)

AGAlumB

Hey, thanks for your interest in the 1Password CLI app! I'm glad Connor was able to help. This is his baby. :)

twx

Updated to 0.5.5 now.
Unfortunately the error is still there. :(

Interesting is this:

#> sudo dtruss ./op update
dtrace: system integrity protection is on, some features will not be available

SYSCALL(args)        = return
You are running the latest version (0.5.5). Thank you for staying up-to-date!
dtrace: error on enabled probe ID 2198 (ID 557: syscall::sysctl:return): invalid kernel access in action #10 at DIF offset 28
[...]

So while using dtruss to analyse the process it somehow executes it different and responds properly.

twx

Which led me to try sudo op update which worked!
But op update still does not.

cohix

@twx well now that is just straight bizarre. I use op on a Mac all day every day and I've never seen anything that would make sudo change the behavior of it...

Does it make the other commands such as signin work?

twx

Other commands like sudo op signing work but at the end it still does not possible to view items.
I tried another local userprofile on my machine op update works. So its appears to be something with my local profile. (I have no other problems with my machine)

What I noticed is that while I run op update when I checked the process hierarchy I found that /usr/bin/security processes are launched.
Doing ps aux | grep security while op update is running I see processes like:

<bla> 4:15PM /usr/bin/security verify-cert -c /var/folders/x7/<someid>/T/cert186598764 -l -L
<bla> 4:15PM /usr/bin/security verify-cert -c /var/folders/x7/<someid>/T/cert658640554 -l -L
<bla> 4:15PM /usr/bin/security verify-cert -c /var/folders/x7/<someid>/T/cert380141019 -l -L
<bla> 4:15PM /usr/bin/security verify-cert -c /var/folders/x7/<someid>/T/cert589009921 -l -L

Assuming I am not too slow re-running the /usr/bin/security command with its parameters it gives:
***Error reading file /var/folders/x7/<someid>/T/cert186598764

Then I checked if these cert* files really exist and I was able to find/view one of the listed cert* files in that folder.

So maybe verifying the https certificate fails because of ... something which breaks the command?

twx

Oh a bad typo:

Then I checked if these cert* files really exist and I was NOT able to find/view one of the listed cert* files in that folder.

cohix

@twx that is good information to have. Do either your normal profile, or the second one you used to test, have root privileges?

twx

The profile I work with has admin permissions and allows sudo for me.
The other was a temporary local user I created for that test that did not have sudo permissions.

c__

@twx Is this a work machine — does your user profile have some special root/intermediary certificate authority configuration installed by your IT, maybe? When I connect to app-updates.agilebits.com:443 with openssl s_client to debug, I see:

depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = app-updates.agilebits.com
verify return:1
---
Certificate chain
 0 s:CN = app-updates.agilebits.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

It might be something to do with the intermediary CAs. It seems something is weird with just your user profile and not the rest of the machine in general.

twx

Hey @c__

it is a work machine. There are special certificates. All my colleagues do not have this problem.

However: I was able to fix it.
I think my solution is not something one should try out without knowing what this means.
So you have been warned: I have removed all entries from the "Certificates" folder from my Keychain.
And after a reboot everything works, update, signin, list  🎉

#> op update
You are running the latest version (0.5.5). Thank you for staying up-to-date!

Thanks for your help!

cohix

That's great to hear @twx ! I was stumped :)

mickael

@twx Just forgot to thank you so much for sharing your solution here. I experienced the same issue with my MBP because I had a lot of custom self-signed certificates installed locally.

Thanks to your post, I finally found the issue and did some cleanup to have again a reliable and relatively fast 1password CLI.

cohix

Glad to hear it @mickael. I have it on my todo list to see if there is anything we can do. The TLS handshake is something handled by the Go stdlib, so I'll have to go see what knobs and levers are available to tweak the behavior there.

holyketzer

Guys, thank you a lot! I had this issue more than 1 year. Absolutely same symptoms that @twx had.

This issue is very consistent with all written in Go products I had it with: Vault, Kubernetes, Minikube and something else.
Finally I started o clean my keychain step by step and after I removed a bunch of strange wildcard certificates it started to work.

I'm curious how they are appeared in my system

twx

Happy to hear that my "solution" works for you guys :chuffed:

cohix

Thanks again for figuring that out @twx !