Connecting to Linkedin SSL error

[ikonkere]

Connecting to https://linkedin.com gives an SSL error (see screenshot). It works with desktop Tor browser, so i suppose it's not a Linkedin issue?

I tried to reduce security levels to 1 and also downgrade TLS in the settings, but nothing helped.

iOS 13.3.1
OnionBrowser 2.5.0

[tladesignz]

Sorry, but can't reproduce.
It could be, however unlikely, that the exit node meddles with the certificate.

Can you try switching circuits?

If this happens all the time for you, can you post a screenshot of a typical circuit?

In which country are you?

[ikonkere]

Hmm, how do i switch circuits on mobile, or even see the current circuit (that was my first guess, but couldn't find an option to do so)? I wouldn't like to disclose my country of origin publicly, but i can do so in a PM if you don't mind.

It could be, however unlikely, that the exit node meddles with the certificate.

This was also something that came to my mind, as i know a thing or two about SSL, but again, it shouldn't matter if desktop works (unless there's a specific faulty exit node for some reason).

[ikonkere]

PS. I tested it with both mobile and desktop devices being on the same LAN [at home], so it's unlikely to do with my country of origin.

[tladesignz]

Hmm, how do i switch circuits on mobile, or even see the current circuit

Open another website which works, then tap the onion icon in the top right.

I wouldn't like to disclose my country of origin publicly, but i can do so in a PM if you don't mind.

Ok, nevermind.

It could be, however unlikely, that the exit node meddles with the certificate.
This was also something that came to my mind, as i know a thing or two about SSL, but again, it shouldn't matter if desktop works (unless there's a specific faulty exit node for some reason).

These two things aren't in any way connected. You most probably don't ever use the same exit node on both devices.

The real question is: Is this behaviour persistent in Onion Browser?

PS. I tested it with both mobile and desktop devices being on the same LAN [at home], so it's unlikely to do with my country of origin.

You mean, because it worked on desktop Tor browser?

Most probably not. Your country shouldn't be able to mess with entry nodes, besides blocking them completely.
Theoretically, though, they could steer you to an entry node they control, if they block access to all others. I guess, the entry node could also mess up the TLS wrapping.

Are you sure you use the same configuration on both devices? Esp. important: Do you use (the same) bridges on both devices? (Or none on both?)

You should definitely try changing to a bridge.

Another possibility: Maybe LinkedIn uses a faulty certificate in the region, the exit node is served from?

[mtigas]

could also be a difference between Tor Browser's CA certificate trust and iOS/Safari's? does this error happen in Safari on the same iOS device?

(We just set up securedrop again at work and noticed a weird issue where our naked domain https://propublica.org/ was getting an error in TBB but not other browsers, until I swapped over to another cert. so kind of the opposite of this problem. so just an idea.)

---

I don't see anything unusual on their end:

$ echo "" | openssl s_client -host www.linkedin.com -port 443
CONNECTED(00000005)
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=www.linkedin.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG1DCCBbygAwIBAgIQB8nVmvce47nbeQpkupsYozANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTkxMTIxMDAwMDAwWhcN
MjAwOTAxMTIwMDAwWjB0MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEdMBsGA1UEChMUTGlua2VkSW4gQ29y
cG9yYXRpb24xGTAXBgNVBAMTEHd3dy5saW5rZWRpbi5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC7EIO7ZCS57AL7mW79kZ0rR3rfWYksMQnt1NQG
fbLI88qxIqg6DMp8TNteTfeWQKpy0JFm4zTNjaSmA0UxKLBPERe67/gGAT1xjINN
Ux/iOFcj1H7y/1gs7SVsJ6JFmCgPIXID8AeOtHYe8dzVpYPAEXIYi93H58menJa1
1h5gl3Pfh9nkp9J5B3YK9reXIulcu6Kp8YCLcVT+LIrQzO8S46mHsh9sjLOoDeM5
nk7C2+kjgFPE00wYweECBFjnzDaFimJa7W6NiZdrTMbJiV0QSlYWCtBm/ex8oRnv
69aHwqGU9aFDYXXYe8soq4UzBoxUeUKrILYdTX4csK+VHoMLAgMBAAGjggOHMIID
gzAfBgNVHSMEGDAWgBQPgGEcgjFh1S8o541GOLQs4cbZ4jAdBgNVHQ4EFgQUlN2C
s4TYrUJ+AeD/6tPeT+VBk80wgcEGA1UdEQSBuTCBtoIMbGlua2VkaW4uY29tghB3
d3cubGlua2VkaW4uY29tgg9tZWRpYS5saWNkbi5jb22CEHN0YXRpYy5saWNkbi5j
b22CFWV4cDEud3d3LmxpbmtlZGluLmNvbYIVZXhwMi53d3cubGlua2VkaW4uY29t
ghVleHAzLnd3dy5saW5rZWRpbi5jb22CFWV4cDQud3d3LmxpbmtlZGluLmNvbYIV
ZXhwNS53d3cubGlua2VkaW4uY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwawYDVR0fBGQwYjAvoC2gK4YpaHR0cDovL2Ny
bDMuZGlnaWNlcnQuY29tL3NzY2Etc2hhMi1nNi5jcmwwL6AtoCuGKWh0dHA6Ly9j
cmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLXNoYTItZzYuY3JsMEwGA1UdIARFMEMwNwYJ
YIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwCAYGZ4EMAQICMHwGCCsGAQUFBwEBBHAwbjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AuZGlnaWNlcnQuY29tMEYGCCsGAQUFBzAChjpodHRwOi8vY2FjZXJ0
cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyU2VjdXJlU2VydmVyQ0EuY3J0MAwG
A1UdEwEB/wQCMAAwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdgCkuQmQtBhYFIe7
E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAW6Lx3eAAAAEAwBHMEUCIGHilMxyKUNv
MRqTQilDnCtn/qECqCutBcDa2Hrws53VAiEAj6rY/sci0mitE6W0YvxphBZEivAu
KMfXu4wBMCcKz7AAdwBep3P531bA57U2SH3QSeAyepGaDIShEhKEGHWWgXFFWAAA
AW6Lx3b0AAAEAwBIMEYCIQD2lQILNYQhvdOyiz/Tp+EFFrDOV2vi8rA1MlokKB2W
jgIhAKub4oVtaLMN/t96V3V4RffykJ0uaKC0UfMQMGvuAuhXMA0GCSqGSIb3DQEB
CwUAA4IBAQB15VzT0KuRJTYZFa+F8NrZlpPY37y7d49oI/sQtItnh3FjvzyG889e
6ao0KCWNgRDM1BOLxe/Q9Gz2TdQjYTfaqLGZfQCY+Qob8/0lHeP27IRPEMbKZGP6
KMjOq0CmKX+lWGziOczQtC9xnZyFyrMFkNtyYaQLgORloTAufyK4wnXsaTpoERAS
5TYu0ipWWnP9vNoPfxHeOF0+rZQwjsHUc6ZdsVHRJYy/9Xd4+fCdWjcBoNYuqqR7
GU/S3NWpIJiRmrpL3B6sJVx5jgGq3ru4GqJ5U2/hQm4v3ZAypgLouxYeYCwECjPH
Y+SC1/NVIu/PsTWGG6MqzW0bTXSaQwqc
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=www.linkedin.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3584 bytes and written 289 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 7623E33B5F83ADBE9DC62D3054423288C4766FB733A2E7518927A9A6B8FD713B
    Session-ID-ctx: 
    Master-Key: 460AF946E6BD1DA41D1B2172135DA1C0F32345DAE1B9232CD36E85AFB5E2DDA6C110E4D203BAC1C36110A2C22BB41E3E
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 63 fe fd 98 34 2a 4e e8-ec f0 9f 30 59 38 84 92   c...4*N....0Y8..
    0010 - 52 dd 05 e0 fd 87 dd a7-6d 5e 59 24 85 cd f5 96   R.......m^Y$....
    0020 - c7 78 2e cb 40 87 b0 54-6f 17 9e 16 8f 4b 67 55   .x..@..To....KgU
    0030 - 3e 02 fe 07 f7 c4 fd 74-c5 4f ac f3 c7 b6 ef 0c   >......t.O......
    0040 - 70 32 0e 9d fb f8 81 7e-f2 31 c1 2a ca 9f 83 8f   p2.....~.1.*....
    0050 - 23 8d 31 4e 4f 37 b7 08-f6 37 71 ea 9d d1 ba 00   #.1NO7...7q.....
    0060 - c8 96 a3 d0 28 9a 4a 35-6d 28 a2 5e 46 8a ca 05   ....(.J5m(.^F...
    0070 - 3e 9b 41 fa f1 e6 ac c8-52 cb 05 46 74 1b 93 fd   >.A.....R..Ft...
    0080 - 0a b4 a0 fe a2 17 e7 b1-ff 98 2f 32 d2 a2 42 05   ........../2..B.
    0090 - e6 3c ba 3f 33 e0 6e de-22 67 5b 85 6d 47 a4 ce   .<.?3.n."g[.mG..
    00a0 - 32 fa 53 b7 7a 25 c9 b7-0b 2d a8 95 99 68 9b 02   2.S.z%...-...h..
    00b0 - 81 76 01 ec 84 c3 f9 1e-8e f8 90 79 e4 0b cd 30   .v.........y...0

    Start Time: 1583880129
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

SSL Labs' test seems to show www.linkedin.com allowing TLS 1.0 and TLS 1.1 connections in IPv6 but not on the IPv4 IP address; and they seem to support a bunch of weaker ciphers, though in our case that shouldn't matter b/c iOS/WebKit should just use the stronger supported ones.

so could be some weird interaction between our TLS requirements and the way their servers are responding.

[ikonkere]

does this error happen in Safari on the same iOS device?

The reason i access Linkedin via Tor is that it's blocked in my country :), so no way to test that.

Are you sure you use the same configuration on both devices? Esp. important: Do you use (the same) bridges on both devices? (Or none on both?)

None on both.

You should definitely try changing to a bridge.

Tried both obfs4 and meek-azure, none of it helped.

Another possibility: Maybe LinkedIn uses a faulty certificate in the region, the exit node is served from?

There's no way of knowing it, because the cirquit isn't established. Each tab in OB has its own cirquit right?

The real question is: Is this behaviour persistent in Onion Browser?

Well, it is persistent for me :). I'm trying linkedin.com for two days now without success.

[ikonkere]

Oookay, seems there's something wrong with my device, as it also works from other phones. Is there a way to diagnose it, maybe check OB's internal logs or something?

[mtigas]

What version iOS and what device model? (In the Settings app -> General -> About: Software Version, Model Name, and Model Number would be the most useful.)

[ikonkere]

iPhone 6s (A1688)
iOS 13.3.1

[tladesignz]

could also be a difference between Tor Browser's CA certificate trust and iOS/Safari's? does this error happen in Safari on the same iOS device?

It works for me. I would think, the root CAs are the same on iOS on every device, aren't they?

And the cert I see in Onion Browser looks pretty much like the one you posted.

Another possibility: Maybe LinkedIn uses a faulty certificate in the region, the exit node is served from?
There's no way of knowing it, because the cirquit isn't established. Each tab in OB has its own cirquit right?

Well, Tor normally creates circuits per domain. Typically, the entry node stays the same, though. There's a UI issue in your edge case, as OB doesn't show the circuits, as long as the page doesn't load at all. :-/

The real question is: Is this behaviour persistent in Onion Browser?
Well, it is persistent for me :). I'm trying linkedin.com for two days now without success.

In that case, it definitely has nothing to do with the exit nodes, because they would have changed by now.

Just make sure that the entry node changes. Browse to a working website, tap the onion icon, press "New circuit for this page". Actually, all circuits will be removed and fresh ones created on the next request.

Oookay, seems there's something wrong with my device, as it also works from other phones. Is there a way to diagnose it, maybe check OB's internal logs or something?

Nope, sorry.

But this points in another direction:

Did you somehow manage to change the list of trusted root CAs? Is your device under company device management?

[ikonkere]

Did you somehow manage to change the list of trusted root CAs? Is your device under company device management?

I certainly have some corporate profiles installed, which contain certificate chains for EAP-TLS authentication. You think it might somehow alter the list of root CAs? Is it possible to check this list out in iOS?

Right, so it seems to definitely be on my end and will likely happen with any HTTPS url i try to open:

But opening https://repo.maven.apache.org/maven2/ in Safari on iOS works!

Can't help but notice the error message could be improved as to actually show what SSL error occurred, so we wouldn't have had to guess - is this to do with my phone, or with CA chains, or with the way OB works with iOS retrieving certificates.

[tladesignz]

Unfortunately, the buit-in root CA list cannot be seen on iOS. At least, not with onboard resources.

This all looks, like you should avoid that device as much as possible. There's something going on and I bet it's about trying to listen in on your secure connections.

The error message you see comes from iOS itself. So we can't do much about it. I never saw that error message, and it isn't even recognized as a TLS error. (Because then, it would have given you the option to ignore it. - For folks surfing to self-signed sites...)

However, I added some code which adds the error code and domain on unknown errors, so after the next release, you can send in more informative screenshots. :-)

I'll close this now, as I don't see how we could improve any more here.

Thanks for your insights and keep yourself secure!

[ikonkere]

The error message you see comes from iOS itself. So we can't do much about it. I never saw that error message

Oh, i see, i guess there's not much for you to do indeed, it's likely not an issue with OB anyway. Thanks for great help and for being patient and friendly :).

like you should avoid that device as much as possible. There's something going on

Come on, can't be that bad! Maybe the root issue lies in the fact that even though the device itself is rather new, the iOS image travelled with me since 2008 (i've never done a fresh start on a new device, just restored old iOS backups), who knows what garbage it accumulated for all that time.

[tladesignz]

Oh, i see, i guess there's not much for you to do indeed, it's likely not an issue with OB anyway. Thanks for great help and for being patient and friendly :).

You're welcome!

Come on, can't be that bad! Maybe the root issue lies in the fact that even though the device itself is rather new, the iOS image travelled with me since 2008 (i've never done a fresh start on a new device, just restored old iOS backups), who knows what garbage it accumulated for all that time.

AFAIK, system stuff is not dragged along, but freshly reinstalled. Just settings, apps and user data are copied from backups.

If that's a company device and you have some device management running from your company, this device is not safe for private use! This fact is valid for everybody in every country. Don't use it for private things!