All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
I think I'm being MITM by my ISP
I'll try to explain my current situation without disclosing too much personal information about myself. Sorry in advance if the post is long.
I recently move to a new country. I move pretty often, so my laptop is always on VPN (no leak), but I also have a 2nd laptop that doesn't use a VPN at all.
Today, I notice that the famous phub website is blocked on my 2nd laptop, which is something that has never happened to be before. Note that I'm only using 1.1.1.1 and 8.8.8.8 as the DNS server, not ISP's. So I tried manual DNS query using both computers, and they show the same correct result.
$ host <redacted> # 1st computer with VPN
<redacted> has address 66.254.114.14
$ host <redacted> # 2nd computer without VPN
<redacted> has address 66.254.114.14
Something feels very off, so I try to investigate a bit more on the 2nd laptop.
$ curl -4 https://<redacted>
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <redacted>:443
$ curl -4 -v https://<redacted>
* Expire in 0 ms for 6 (transfer 0x55f86c341fb0)
* Expire in 1 ms for 1 (transfer 0x55f86c341fb0)
* Expire in 0 ms for 1 (transfer 0x55f86c341fb0)
<A lot of expiration here>
* Trying 66.254.114.41...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f86c341fb0)
* Connected to <redacted> (66.254.114.41) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <redacted>:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <redacted>:443
$ curl -4 -v -k https://66.254.114.41
<Successful connection here / HTML title: Down for Maintenance 403>
On Wireshark the traffic looks like this. Notice the first packet after the TCP handshake. Also note that --tlsv1.2 and --tlsv1.3 doesn't change anything.
Laptop -> Server: SYN
Server -> Laptop: SYN, ACK
Laptop -> Server: ACK
Laptop -> Server: TLSv1 Client Hello [Version TLS 1.0 (0x0301)]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Laptop -> Server: Retransmission [PSH, ACK]
Server -> Laptop: FIN, ACK
Laptop -> Server: FIN, ACK
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#1 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#2 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#3 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#4 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#5 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#6 [ACK]
Server -> Laptop: Retransmission [FIN, ACK]
Laptop -> Server: TCP Dup ACK#7 [ACK]
At this point I'm pretty sure that my traffic is being MITM, so I check a couple of sites for mismatched fingerprints to confirm. Just to be overly safe, I don't include the fingerprints from the 2nd laptop here, but feel free to reach out if you want proof.
# Facebook - 1st computer with VPN
Issuer Name:
Country: US
Organization: DigiCert Inc
Organizational Unit: www.digicert.com
Common Name: DigiCert SHA2 High Assurance Server CA
Validity:
Not Before: 7/31/2021, 2:00:00 AM (Central European Summer Time)
Not After: 10/30/2021, 1:59:59 AM (Central European Summer Time)
Fingerprints:
SHA-256: C4:14:EF:EB:D7:CC:6D:4B:56:B5:42:6B:B9:65:13:7B:5D:AA:7B:C8:BB:88:3C:8E:8D:08:96:CF:0A:E9:A2:96
SHA-1: 12:77:BA:B8:5F:2F:C5:57:7B:32:02:52:C7:92:B2:C8:ED:14:C6:87
# Facebook - 2nd computer with VPN
Issuer Name:
Country: US
Organization: DigiCert Inc
Organizational Unit: www.digicert.com
Common Name: DigiCert SHA2 High Assurance Server CA
Validity:
Not Before: 9/<redacted>/2021, 2:00:00 AM (Central European Summer Time)
Not After: 12/<redacted>/2021, 1:59:59 AM (Central European Summer Time)
Fingerprints:
SHA-256: Not the one above
SHA-1: Not the one above
# Twitter - 1st computer with VPN
Issuer Name:
Country: US
Organization: DigiCert Inc
Common Name: DigiCert TLS RSA SHA256 2020 CA1
Validity:
Not Before: 1/12/2021, 1:00:00 AM (Central European Summer Time)
Not After: 1/12/2022, 12:59:59 AM (Central European Summer Time)
Fingerprints:
SHA-256: 29:2D:FE:1E:9E:BC:44:78:A6:26:BF:5A:FD:FC:3F:94:1C:5F:AE:10:DD:A9:3C:6A:43:1D:A1:21:93:83:98:FD
SHA-1: D3:D6:3F:81:7C:78:6C:D5:4E:56:AF:DD:07:A2:30:7C:1E:33:AF:73
# Twitter - 2nd computer with VPN
Issuer Name:
Country: US
Organization: DigiCert Inc
Common Name: DigiCert TLS RSA SHA256 2020 CA1
Validity:
Not Before: 2/<redacted>/2021, 1:00:00 AM (Central European Summer Time)
Not After: 2/<redacted>/2021, 12:59:59 AM (Central European Summer Time)
Fingerprints:
SHA-256: Not the one above
SHA-1: Not the one above
Wikipedia
# Wikipedia - 1st computer with VPN
Issuer Name:
Country: US
Organization: Let's Encrypt
Common Name: R3
Validity:
Not Before: 9/13/2021, 10:02:37 AM (Central European Summer Time)
Not After: 12/12/2021, 9:02:36 AM (Central European Summer Time)
Fingerprints:
SHA-256: B0:B2:11:02:2D:1A:C8:C9:8D:12:6C:B1:A4:4B:7F:1D:D3:6D:84:9D:2E:F7:76:93:76:62:5D:07:EB:1F:BA:94
SHA-1: C5:23:79:F6:50:0E:62:C1:30:0D:AE:9F:1B:68:1F:45:CA:5D:DB:01
# Wikipedia - 2nd computer with VPN
Issuer Name:
Country: US
Organization: DigiCert Inc
Organizational Unit: www.digicert.com
Common Name: DigiCert SHA2 High Assurance Server CA
Validity:
Not Before: 11/<redacted>/2020, 1:00:00 AM (Central European Summer Time)
Not After: 11/<redacted>/2021, 12:59:59 AM (Central European Summer Time)
Fingerprints:
SHA-256: Not the one above
SHA-1: Not the one above
Please help. I'm not sure what to do now. The router is from the ISP and no one has the credential for the admin interface. I also have no reason to believe that I'm being MITM by a random neighbor.
Comments
I don’t think attacker can issue a valid SSL.
You don't need help.
I thought so too. That's why I don't think it's a random neighbor. But I could be just paranoid.
Well
lbtube(dot)com
Interesting choice
You need help.
Enable MAC address filtering in your ISP router.
To improve the security of your Wi-Fi network, consider using MAC address filtering to prevent devices from authenticating with your router.
https://www.lifewire.com/enabling-mac-address-filtering-wireless-router-816571
Can you look up the suspect certificate serial number on crt.sh and check if it's a valid cert? I believe if the serial doesn't match, you would probably also get a SSL error when trying to connect to the website (without having trusted the certificate first)
Is your connection running behind CGNAT? Or it's assigned public IP by the ISP? just wondering..
If a browser-trusted CA issued a certificate to someone other than the domain owner, report them to the browsers.
The CA would be distrusted.
Unless, you installed a CA certificate from your ISP, then they can do anything they want.
That's why you should normally avoid "ASDL dialer" app on your computer, and dial ASDL on a home router or with the OS built-in feature.
I have no reasons to make this up. At best I'm simply misunderstood some network theory, and at worst idk. Pick a better time to troll.
I can tell you for sure that it's not a public IP, and quite likely it's behind CGNAT.
I'm currently not at home but I'll do it when I get back. Neither Google Chrome nor Firefox suspects a thing about certs though.
I've already specified the CA in the first post, all DigiCert but not the exact Common Name. I also specified that I've just arrived here recently, and haven't installed any CA certs.
Dump full chain and share with the community. If there is indeed an unreported cert issued by a trusted CA, as @yoursunny has noted, CAB forum will be enticed to look into it.
The main sticking point seems to be Wikipedia using Let's Encrypt vs DigiCert. It does use DigiCert for me. For how you got Let's Encrypt, maybe you have a typo in the domain name tested?
All others use the same CA albeit with different fingerprints. I believe it might be common to get different certs depending on which node in the CDN you land onto.
For the ISP MITM, of course they do MITM you if the country has website censorship. You see the effect of that in
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection
. But they cannot provide valid trusted certs for websites other than their own, unless your PC is also backdoored and had fake root certs installed as trusted in the cert store.Wikimedia actually uses both DigiCert and Let's Encrypt on purpose. From https://wikitech.wikimedia.org/wiki/HTTPS:
You can find all certificates issued to wikipedia.org on the CT logs: https://crt.sh/?q=wikipedia.org
Sounds like the fake wall
The term
Man In The Middle
Is balatantly sexist.
So, after reading the comments and further testing, it appears that I'm way too paranoid.
The ISP is indeed using SNI blocking for censorship. But the SSL problem is false. I was under the assumption that all nodes in the CDN should share the same cert (because why not ?).
Thanks everyone for helping.
I also prefer a woman in the middle.
MITM with a woman on either side is also welcome.
I prefer woman on both side
first, social justice warriors changed us master to main on git, and now it will be (W)MITM...
The two are not mutually exclusive.
Is that typo? ADSL?
Some security tips for your own domain:
1) Monitor if any CA is issuing certificates for your domains through any CT monitor tool. Cloudflare have one if you add your domain in their realms. Although CT's would probably not log this.
Context: https://docs.digicert.com/manage-certificates/logging-public-ssl-tls-certificates-to-public-ct/methods-keeping-ssl-tls-certificates-out-of-ct/
2) Use DNS CAA records to tell CA's to fuck off don't issue my certificate
3) Use DNSSEC zone signing