On 26/09/2016 08:42, Ronald F. Guilmette wrote: > > Sorry folks. I'm almost entirely ignorant about everything crypto, > and these questions would probably be better asked elsewhere, but > you all on this list are nicer that folks elsewhere, and probably > will have the kindness not to poke too much fun at my ignorance. > So, here goes... > > First question: Regarding the specific kind of MiM deception > being discussed in the following old article (which appears to > be from way back in 2010), I'm confused by the assertion that > it would be necessary to either bribe or bully some CA into > handing out a fradulent cert in order to make the scheme work: > > https://www.wired.com/2010/03/packet-forensics/ > > Here's my point: If you really have already managed to become > the man-in-the-middle anyway, then couldn't you just dummy up > any and all responses, including those for DNS, in such a way > as to make it all appear to the victim that everything was > "normal", you know, such that he can see the cute little > padlock symbol to the left of the URL in the browser?
The article doesn't make it entirely clear, but they are talking about encrypted web traffic here. In this case the MitM attacker acts as a proxy between you and the real web site you're attempting to contact. In order to gaid any advantage through being the man in the middle, they have to see the plaintext of the traffic you're sending to the intended site (plus they'd need the plaintext if they were intending to alter the traffic as it passed through -- think of them changing the destination or amount of a payment from your on-line banking servers for example). So they need to receive your HTTPS traffic, decrypt it, scan it for interesting stuff or modify it, and then re-encrypt it and send it on to the original destination as if it came directly from you. Similarly in reverse for the responses from the original site. Now, the MitM can easily set up a HTTPS server, but what they should not be able to do is get a TLS certificate in the name of the domain they are trying to spoof. So your browser should warn you about the DN of the certificate not matching the URL you're attempting to reach. This should be the case if the Certification Authority system is working as intended. Mostly it does, but there have been cases where, either through lax procedure or malfeasance a site certificate has been issued to some third party who does not own the site in question. There are also cases of Certification Authorities under the control of repressive regimes who will issue certificates for Google or Facebook or whatever on behalf of their government, thus enabling that government to spy on their citizen's supposedly secure web traffic. Those government controlled CAs were in the global lists of trusted CAs baked into web browsers and available as the ca_root_nss package, so browsers would automatically trust certificates issued by them. At least until this spoofing action was discovered, when they were dropped from the trusted list with extreme alacrity. (Is your copy of ca_root_nss up to date?) > Second question: I've been trying to do some very simple- > minded early reconnaissance on something that I believe to be > a Really Bad Domain. The web site for the domain doesn't > appear to use SSL at all, however when I went to this site: > > https://censys.io/ > > and punched in teh domain name and then clicked on "certificates" > I was surprised to find three different ones shown for the domain > in question, all three apparently issued by "Let's Encrypt Authority > X3". So anyway, my question is real simple: Is there some way to > work backwards from those in order to get some clues... any clues... > about the identities of the actual owners/operators of this specific > domain and/or its associated web site? > > Thanks in advance for any and all enlightenment. Hmmm... their TLS certificate is issued by 'StartCom Class 1 DV Server CA' This is a CA that prominently advertizes free SSL certificates, but otherwise looks like it charges just like any other CA. See: http://www.startssl.com/ No idea if this CA is any good but there's nothing to suggest any wrong doing just from their site. Neither is there anything apparently wrong with censys.io -- in fact the censys.io site looks like a very useful research tool. Well, except it seems to have no clue about IPv6 which is pretty useless in this day and age. Cheers, Matthew
signature.asc
Description: OpenPGP digital signature
