Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › I think I'm being MITM by my ISP
New on LowEndTalk? Please Register and read our Community Rules.

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

b0ltb0lt Member
in Help

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

# 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

# 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

  • gianggiang Veteran

    I don’t think attacker can issue a valid SSL.

    Thanked by 1dystopia
  • deankdeank Member, Troll

    You don't need help.

    Thanked by 3jenkki b0lt dystopia
  • jenkkijenkki Member

  • b0ltb0lt Member

    @giang said:
    I don’t think attacker can issue a valid SSL.

    I thought so too. That's why I don't think it's a random neighbor. But I could be just paranoid.

    @deank said:
    You don't need help.

    Well

  • jmgcaguiclajmgcaguicla Member

    <redacted> has address 66.254.114.14

    lbtube(dot)com

    Interesting choice

    image

  • cybertechcybertech Member

    You need help.

  • Tony40Tony40 Member

    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

  • bulbasaurbulbasaur Member
    edited October 2021

    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)

  • nanankcorneringnanankcornering Member

    Is your connection running behind CGNAT? Or it's assigned public IP by the ISP? just wondering..

  • yoursunnyyoursunny Member, IPv6 Advocate

    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.

    Thanked by 2b0lt Boogeyman
  • b0ltb0lt Member
    edited October 2021

    @jenkki said:

    @cybertech said:
    You need help.

    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.

    @nanankcornering said:
    Is your connection running behind CGNAT? Or it's assigned public IP by the ISP? just wondering..

    I can tell you for sure that it's not a public IP, and quite likely it's behind CGNAT.

    @stevewatson301 said:
    Can you look up the suspect certificate serial number on crt.sh and check if it's a valid cert?

    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.

    @yoursunny said:
    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'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.

  • jenkkijenkki Member

    @b0lt said: At best I'm simply misunderstood some network theory, and at worst idk.

  • IziDIziD Member

    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.

    Thanked by 2b0lt yoursunny
  • rm_rm_ IPv6 Advocate, Veteran
    edited October 2021

    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.

    Thanked by 2b0lt vimalware
  • udonworldudonworld Member

    @rm_ said: 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?

    Wikimedia actually uses both DigiCert and Let's Encrypt on purpose. From https://wikitech.wikimedia.org/wiki/HTTPS:

    We deploy the LE cert at our US edges and the Digicert cert at our non-US edges, so that both see constant live use and are known-good options in the case that emergency operations require us to switch all edge sites to just one of the two.

    You can find all certificates issued to wikipedia.org on the CT logs: https://crt.sh/?q=wikipedia.org

    Thanked by 3rm_ b0lt vimalware
  • dahartigandahartigan Member

    Sounds like the fake wall

  • vyas11vyas11 Member

    The term
    Man In The Middle
    Is balatantly sexist.

    Thanked by 2Maounique dystopia
  • b0ltb0lt Member

    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.

  • MaouniqueMaounique Host Rep, Veteran

    @vyas11 said:
    The term
    Man In The Middle
    Is balatantly sexist.

    I also prefer a woman in the middle.

    Thanked by 1vyas11
  • vyas11vyas11 Member

    @Maounique said:

    @vyas11 said:
    The term
    Man In The Middle
    Is balatantly sexist.

    I also prefer a woman in the middle.

    MITM with a woman on either side is also welcome.

  • chocolateshirtchocolateshirt Member

    @vyas11 said:

    @Maounique said:

    @vyas11 said:
    The term
    Man In The Middle
    Is balatantly sexist.

    I also prefer a woman in the middle.

    MITM with a woman on either side is also welcome.

    I prefer woman on both side

  • AndrewsAndrews Member

    first, social justice warriors changed us master to main on git, and now it will be (W)MITM...

  • MaouniqueMaounique Host Rep, Veteran

    @chocolateshirt said: I prefer woman on both side

    @Maounique said: I also prefer a woman in the middle.

    The two are not mutually exclusive.

    Thanked by 2vyas11 chocolateshirt
  • BoogeymanBoogeyman Member

    @yoursunny said: "ASDL dialer" app on your computer, and dial ASDL on a home router or with the OS built-in feature.

    Is that typo? ADSL?

    Thanked by 1yoursunny
  • BoogeymanBoogeyman Member

    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

    Thanked by 1b0lt
Sign In or Register to comment.