Two Dumb Questions

Matthew Seaman matthew at
Mon Sep 26 08:31:17 UTC 2016

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:
> 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:
> 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:  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 -- in fact the 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the freebsd-security mailing list