NoSnoop – Find out if your HTTPS traffic is being monitored
trustprobe.com
trustprobe.com
Otherwise, if the method of intercepting the traffic only manipulates the browser (for example a rogue extension or proxy setting you were not aware of), a standalone tool could not detect it. Right?
Also, I would generally avoid any security tools that do not come as source code. Mentioning that you are an infosec guy with 15 years of experience only makes this point hit even harder.
https://addons.mozilla.org/en-GB/firefox/addon/certainly-som...
The site is still up. https://perspectives-project.org
https://bugzilla.mozilla.org/show_bug.cgi?id=1435951 https://bugzilla.mozilla.org/show_bug.cgi?id=1489080
Honestly I had forgot all about that addon until Mizza mentioned it, but I remember being so impressed by the idea back when I first learned about it. I wish we could bring it back.
well it says this so no reason to distrust it :)
So nothing major is detected. That doesn't necessarily mean it's safe. Just... a data point.
www.huawei.com 0 Actalis Authentication Root CA F373B387065A28848AF2F34ACE192BDDC78E9CAC
The software's assumption is that (for some sites at least) the author can check what the "right" certificate is and if you see a different one that's wrong.
That clearly won't work for some sites any of the time, they use a CDN to present different behaviour including certificates in different places, and presumably the author weeds those out. But as we see here it can't work for _any_ site all the time, it will be inconsistent.
Is there any downside to this? I mean, I have several wildcard certs issued for each of my personal domains mainly because it's more convenient to get separate certs on each host with certbot than trying to sync certs from one host to another. Is there any reason I shouldn't do this?
A bad guy who gets any of the private keys associated with any of these certificates can use that to impersonate any service with the corresponding name, even a quite different one.
So say you've got mail.oefrha.example that's a mail server using a *.oefrha.example cert, and the Dread Pirate Roberts breaks into it, they can use that when impersonating your web server www.oefrha.example or your Q&A site faq.oefrha.example even if those are on totally different hardware that Roberts wasn't able to penetrate.
For older TLS (or SSL) versions there's a trick called implied authentication used with RSA. After showing the certificate, instead of your server signing something to prove it knows the corresponding private key, the client sends something across which your server decrypts. Only the real server could decrypt it with the private key to continue the conversation so authentication is implied. However, in doing this your server has to be _extremely careful_, because it's easy to give away information when things go wrong. If it's not careful enough, a bad guy doesn't learn the key but they can use your answers to work out how you'd sign RSA messages.
This means if you've got old-crap.oefrha.example which does TLS 1.0 with crappy RSA implied auth enabled so as to make it work with some rotten turn of the century tech, and it has a wildcard certificate, some bad guys can maybe exploit that to pretend they are www.oefrha.example even though your actual www.oefrha.example web server only speaks TLS 1.2 or newer with elliptic curves.
You say a "personal domain", and I don't recognise your name, so chances are that this just doesn't matter. We're not talking about something a bored teenager can do, but if real bad guys with resources are attacking you, then it's probably not a smart idea to have so many wildcards.
Edited: Repeatedly to try to get HN's half-arsed parser to stop ruining everything. Gave up. HN use a parser that has working escapes, or remove the parser and just say the site only has text too bad.
For a large organization, this probably just says that they have a lot of different systems and groups operating relatively independently with poor practices, which isn’t an immediate problem but suggests that they’re an easier target than some.
same for me is there reason why though?
So you'll get false positives if the server's database of TLS connection attributes is out-of-date, as is happening to several commenters here.
And you'll get false negatives if the MitM mimics the purported client software, which is easy for a malicious MitM to do.
It should be made to work better. A MITM attach changes the enciphered bits, because it re-encrypts with a different key. So the enciphered bits sent and the enciphered bits received are different. If you can compare a few bits somehow, you can detect MITM attacks.
The early STU-III secure phone displayed a 2-digit number at each end. You were supposed to verify by voice that those numbers were the same. That prevented most MITM attacks.
A web site could send something that says "The first N crypto bytes were 0xa34g", and the browser could check that. An attacker would have to know to fake that to evade the check.
It's possible to make the attacker work very hard to do such a fake. A nice trick would be to have the server send a MD5-type hash of the entire page plus the first encrypted bits early in the web page. Then, send almost all of the web page, but wait a few seconds before sending the last few bytes, which could just be a random HTML comment so rendering doesn't have to wait. To fake that, the attacker not only has to know what to do to fake it, it has to wait for the entire page to transmit before it can send any of the page. So the browser sees a substantial extra delay before the page starts if there's a MITM attack which tries to fake the "first N crypto bytes" check. That's detectable automatically.
It also breaks all caches, so that's a problem.
How should I conclude?
I tried LTE only and I also get the red MITM page.
Edit: tried my laptop on wifi, green OK
On my iPhone, (AT&T LTE) - red MITM page.
iPhone on my WiFi - red MITM page even with the cellular antenna disabled(!)
Tethered my laptop to my phone - red MITM page.
From the GRC fingerprints page FAQ:
"What can go wrong with this test?
"There ARE several things to consider:
"False-Positive Mismatches:
"Smaller web sites, like this one (GRC) and those others listed above, deploy only one security certificate on one or more web servers (For example, our wonderful certificate provider, DigiCert, specifically allows us to use the same single certificate on as many servers as necessary.)
"But companies with a massive and widely distributed web presence, such as Amazon or Google, may deploy many different security certificates across their many globally distributed servers and web sites. Multiple certificates may be easier for them to obtain and manage, and their security is not reduced. But it does mean that not every user of their servers (like you and this GRC page) would necessarily obtain the same security certificate.
"This means that a simple comparison of certificate fingerprints could erroneously lead people wishing to test these huge websites to conclude that their connections were being intercepted, when they have simply received a different valid certificate than the one received and shown by this web page.
"The best solution is to test smaller sites that are known to be using single certificates, or sites using the completely unspoofable extended validation (EV) certificates with an EV-honoring web browser such as Firefox or Chrome (but not Internet Explorer, which doesn't properly verify EV certificates)."
"This website does not collect any personal information." - after taking about the product for the entire page. Note "website", not "software".
Both approaches have advantages and disadvantages (e.g. this one reports false positives if the certificates change, the other either reports false positives if the fingerprints change unexpectedly, or false negatives/inconclusive results if it encounters an unknown fingerprint).
https://security.stackexchange.com/questions/12066/can-i-det...
Simple examples:
1. Analysis of TCP details could detect an intermediary proxy
2. TLS conflicts tell you a bad attacker is trying; use of a certificate from a different CA or an old one tells you someone has been compromised.
3. Attempts to block or throttle TLS, downgrade protocols, or block/degrade access to security updates tells you someone is trying to encourage you to act in an insecure manner.
4. If you send unique canary hostnames or URLs which are accessed, you know something has compromised your traffic.
5. Timing analysis can tell you that some target sites are being treated differently, which could be a sign that traffic is being more tightly monitored (IIRC this has been noticed with the great firewall).
6. HTTP pages can be requested from multiple sources and compared for modifications. I once learned about some JavaScript being injected into pages on Iranian college computers when their code triggered errors this way.
There is also OONI for mobile from TorProject that does the same, app and data are opensource. Available in FDroid
EDIT: www.bbc.co.uk 0 GlobalSign 1F24C630CDA418EF2069FFAD4FDD5F463A1B69AA
www.huawei.com 0 Actalis Authentication Root CA F373B387065A28848AF2F34ACE192BDDC78E9CAC
Doesn't work here or should I be concerned? ;)