[SOLVED] MITM attack.

To rule out an infection on my pc. I tried in my computer Lenovo C200 and I have the same fingerprint of the certificate of twitter that is in an image of the program SSLEye in the first post. It should be noted that the C200 is connected via Wifi. I don't know what it will be. I hope it's just a problem of my ISP. Best regards. Thank you very much.
 
To rule out an infection on my pc. I tried in my computer Lenovo C200 and I have the same fingerprint of the certificate of twitter that is in an image of the program SSLEye in the first post. It should be noted that the C200 is connected via Wifi. I don't know what it will be. I hope it's just a problem of my ISP. Best regards. Thank you very much.
Hi there,

Could you do two things for me? First, can you upload the bad / suspicious certificate? Click the website security padlock > Certificate > Details > Copy to File > .P7B / entire chain (see screenshot below) then zip it up and upload.

47385


Second, could you download FiddlerCap: FiddlerCap - Recording Web Traffic - Telerik

and then use it to record you loading Twitter, first without "Decrypt HTTPS traffic" and then separately with "Decrypt HTTPS traffic" and zip up and upload the two captures here / Microsoft OneDrive / similar?
 
Hi there,

I have finished investigating and I do not believe there is anything suspicious here. I believe both that the certificate is authentic and belongs to Twitter, and that the IP address is non-malicious and belongs to Twitter.

First, let's tackle the IP address.

Doing a Reverse DNS lookup on the IP address 35.186.207.124 gives us the domain 124.207.186.35.bc.googleusercontent.com which does raise questions, but is not immediately necessarily suspicious as Twitter could conceivably be delivering at least part of their website through Google Cloud.

In fact, what is significant here is that there even is a PTR record. This implies both that the IP address is static and that it is entirely controlled by a single entity, in this case Google.

47496

Moreover, there is also a forward A record from gtcp-na.twitter.com to 35.186.207.124. Whilst this doesn't quite guarantee that all content on 35.186.207.124 (which we ascertained above must also be hosted by Google) is safe, it does provide a pretty big reassurance that Twitter themselves trust this IP address.

47497



Next, onto the certificate. Note that the colour seems only to be affected by the SSL certificate hash, not the Extended Validation status (which isn't necessary or particularly relevant for a secure connection anyway).

47498

Furthermore, the certificate hash you see, starting with 15f, is reproducible globally - ruling out a local infection of your router or similar.

47499


Let's then analyse this certificate (which you sent me a copy of).

47500

47501

It's a wildcard certificate for *.twitter.com which naturally won't match a certificate for twitter.com. However, it is in good standing, issued by a reputable authority and EV (which in practice means very little - the fact it is Domain Validated is what matters). This certificate seems in every way to be genuine and authentic.

It is very common practice for large websites to use many different certificates across different parts of their websites. This is perfectly normal and nothing to be concerned about.

In summary what we have is:
A genuine EV certificate in good standing, verifiable globally (ruling out a local infection of your computer, router or even national infrastructure), and a DNS lookup which leads to an IP address - itself forward-confirmed with a googleusercontent.com subdomain - which nevertheless has a forward A record pointing from a true twitter.com subdomain.

In conclusion I see nothing other than a part of Twitter's Content Delivery Network hosting parts of their website on Google Cloud infrastructure, and therefore in overall conclusion, nothing to be concerned about.

EDIT: I should add that there seems to be a slight muddying of the waters between EV (high assurance) and Extended Validation (very high assurance) certificates. For all intents and purposes they are each as secure as the other, except that many companies actually don't want their name to appear in the URL bar anymore, and so opt for high assurance rather than very high assurance. This was a result of market pressure after companies started moving from Extended Validation down to Domain Validation, so certificate providers introduced EV as a step between.

What is the difference between high assurance and low assurance certificates?
 
Last edited:
Excellent research and explanation. I was impressed by the information so accurate and forceful. Thank you very much for your valuable help. Topic solved. Best regards.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top