Two Dumb Questions

[Ronald F. Guilmette]

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
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Matthew D. Fuller]

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) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[RW via freebsd-security]

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.

[Dag-Erling Smørgrav]

RW <rwmai...@googlemail.com> writes:
> 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.

SSL / TLS didn't commonly use DH, much less *safe* DH, until fairly
recently, and DH alone is not very useful. You need either a shared
secret or trusted key pairs to authenticate either or both endpoints.

> 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.

Assuming you can trust the public key, which is what CAs are for, but
CAs can be hacked, deceived or coerced.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Ronald F. Guilmette]

Thanks to everybody who replied, and sorry for being soooo off topic.

In message <74ed7019-cb87-c55a...@FreeBSD.org>,
Matthew Seaman <mat...@FreeBSD.org> wrote:

>> https://www.wired.com/2010/03/packet-forensics/
>>...

>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.

Right. I had assumed all the above.

>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.

Well, see, this gets to the heart of my question, and my ignorance.

If you are the man in the middle, and if the target/victim asks for
the certificate for some spoofed site `X', can't you just give him
back something which is valid for the spoofed site, you know, since
you are in the middle completely anyway?

And also, I read something recently about how some guy was surprised
to find that... due to some temporary cock-up by one CA... he could
get a certificate for foo.bar.tld but he later found that he could
use that also for the superdomain of that, bar.tld. That was a
minor but significant screw up by the CA which was later corrected,
but it does give one reason to wonder about other possible scenarios.

For example, could a MiM perhaps get a cert for wwww.foo.tld (four w's)
and then, if that same MiM is able to send the victom spoofed DNS
responses, when asked for DNS of www.foo.tld, couldn't he/she just
sent back a CNAME which equates www.foo.tld to wwww.foo.tld and then
also run a web server that makes wwww.foo.tld look like the real thing?

Remember, the story I gave a link to (see above) suggested that somebody
has been out there actively selling MiM gear, *and* the story also
suggested that -no- CA was either bullied or bribed into creating any
dodgy certs. So how that box works is still rather mysterious, to me
at least.

>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?)

Thanks. This all is very enlightening. I understand the basics of how
things are "supposed" to work, but other than that, much of what you said
above is news to me.

>> 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

>>...

>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.

Sorry. I apparently wasn't clear. Yes, absolutely, the censys.io web
site appears to me to be a great resarch tool. *It* is *not* the
"Really Bad Domain" that I want to do reconnaissance on. It is just a
research tool that I was using -as- I was doing recon on an entirely
unrelated domain. (I didn't provide the name of that other domain.
Let's just call it somereallyevildomain.com. :-)

So, returning to my question, I punched in "somereallyevildomain.com"
to the censys.io research web site, and it is telling me that the domain
name "somereallyevildomain.com" is associated with three certificates,
all three issued by "Let's Encrypt Authority X3".

I do not know *anything* about the actual *identities* of the people who
are running the somereallyevildomain.com domain or its associated web
site, but I dearly *do* want to try to find out who these evil parties
are. (I do a lot of this kind of thing... finding an outting perpetrators
of all manner of Bad Stuff on the Internet.)

So again, my question is: Given that I have these three certs, is there
any way that I can leverage those into some information... i.e. *any*
information... about the party or parties to whom those cets were issued?
And also: If I can, how would I do that?


Regards,
rfg

[Dag-Erling Smørgrav]

"Ronald F. Guilmette" <r...@tristatelogic.com> writes:
> If you are the man in the middle, and if the target/victim asks for
> the certificate for some spoofed site `X', can't you just give him
> back something which is valid for the spoofed site, you know, since
> you are in the middle completely anyway?

The client should not trust the certificate it gets from the server
unless it can be traced back to a certificate in the client's trust
store. For instance, if the server has a certificate signed by
StartCom, it will transmit its own certificate as well as a copy of
StartCom's intermediate certificate (which was used to sign the server
certificate), which in turn was signed with StartCom's root certificate,
which is in the trust store.

> And also, I read something recently about how some guy was surprised
> to find that... due to some temporary cock-up by one CA... he could
> get a certificate for foo.bar.tld but he later found that he could
> use that also for the superdomain of that, bar.tld. That was a
> minor but significant screw up by the CA which was later corrected,
> but it does give one reason to wonder about other possible scenarios.

This rings a bell, but all I can think of at the moment is the claim
earlier this year that StartSSL (StartCom's CA service) could be tricked
into issuing certificates for any domain to anyone, which turned out to
be false. Also, StartSSL used to automatically add example.com as an
alternate name when you ordered a certificate for foo.example.com (which
you could only do after proving that you owned example.com), but they
stopped doing that.

> For example, could a MiM perhaps get a cert for wwww.foo.tld (four w's)
> and then, if that same MiM is able to send the victom spoofed DNS
> responses, when asked for DNS of www.foo.tld, couldn't he/she just
> sent back a CNAME which equates www.foo.tld to wwww.foo.tld and then
> also run a web server that makes wwww.foo.tld look like the real thing?

I find your scenario confusing, but if I understand you correctly, no.
Browsers don't know or care about CNAMEs. They will try to match the
certificate's distinguished name against the server name that was in the
URL. In your scenario, the victim's browser will expect a certificate
for www.foo.tld and will balk when presented with a certificate for
wwww.foo.tld.

> So again, my question is: Given that I have these three certs, is there
> any way that I can leverage those into some information... i.e. *any*
> information... about the party or parties to whom those cets were issued?

You could try to contact the certificate authority that issued the
certificate and ask, but I doubt they'd answer (if they even know), and
in Let's Encrypt's case, there isn't anyone you can ask.

DES
--
Dag-Erling Smørgrav - d...@des.no

[John-Mark Gurney]

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."

[Nikola Pavlović]

On Mon, 26 Sep 2016 10:31:02 +0200
Matthew Seaman <mat...@FreeBSD.org> wrote:
[...]
> >
> > https://censys.io/
> >

[...]

>
> 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.

Just an FYI regarding StartCom: Mozilla is suspending their CA for
one year (and quite likely forever, it's unlikely they'll be able to
meet the requirements for reactivation). Lots more info here in
Mozilla's investigation report:
https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview


--
PGP: 28CC 9078 8358 CE2D 6824 A5BC 2DB2 CD24 5BE7 8F06