Two Dumb Questions
Ronald F. Guilmette
rfg at tristatelogic.com
Mon Sep 26 20:53:23 UTC 2016
Thanks to everybody who replied, and sorry for being soooo off topic.
In message <74ed7019-cb87-c55a-fb6d-1c016bf04d59 at FreeBSD.org>,
Matthew Seaman <matthew at FreeBSD.org> wrote:
>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
>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:
>> 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
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?
More information about the freebsd-security