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?
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.
Regards,
rfg
Ronald F. Guilmette, and lo! it spake thus:> > 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?Dummying up DNS responses is probably the way you got the user to your site in the first place; that would often be easier than trying to intercept their TCP 80/443 web connect tries. But they're not gonna get the cute little padlock unless the browser is happy with the cert, which is going to mean either the user accepts it through the increasingly-irritating-and-dire warnings, or it's signed by some CA the browser accepts. So, you'd either need to get one of the umpteen common CA's to give you one, or sneak an extra CA into their browser (and if you could do that latter, you could bypass a lot of the spoofing work anyway). -- Matthew Fuller (MF4839) | fullermd at over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 931 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20160926/a90b7b8d/attachment.sig>
On Sun, 25 Sep 2016 23:42:34 -0700 Ronald F. Guilmette wrote:> 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?There's a simple paint analogy here: https://en.wikipedia.org/wiki/Diffie?Hellman_key_exchange that illustrates how it's possible to exchange a shared secret without an eavesdropper knowing what it is. The shared secret can then be used for symmetric encryption using something like AES. Actual protocols use public key cryptography so it can be established that the exchange is end to end, and not broken into two separate exchanges.
Ronald F. Guilmette wrote this message on Sun, Sep 25, 2016 at 23:42 -0700:> 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?As for DNS, that is the reason DNSSEC has been deployed. To ensure that the response is correct. Though if the attacker completely controls your inet connection, they don't even need to do this, as they can just pretend to be any IP they want to be. Cryptography allows you to verify the identity of another party and ensuring it is not tampered with using PKI[1]. There are other forums that are better to ask how this is possible. [1] https://en.wikipedia.org/wiki/Public_key_infrastructure -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."