Date: Mon, 26 Sep 2016 10:31:02 +0200 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions Message-ID: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> References: <32084.1474872154@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c Content-Type: multipart/mixed; boundary="W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-security@freebsd.org Message-ID: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> Subject: Re: Two Dumb Questions References: <32084.1474872154@segfault.tristatelogic.com> In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> --W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 26/09/2016 08:42, Ronald F. Guilmette wrote: >=20 > 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... >=20 > 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: >=20 > https://www.wired.com/2010/03/packet-forensics/ >=20 > 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: >=20 > https://censys.io/ >=20 > 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? >=20 > 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 --W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8-- --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJX6NzOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT60EP/3ROIhv0II18byq93oWXmeFw MTmeOHhyRoS8upS6jOeIxNI+zDB+n+x+6tsuGikYn9P7akXVXX/x6aWyGztNKVwa IUlgTcWCH6s+wavn9mtTHOizs6EhT8UfoUWk0+I3L9YccWzFYf/kA6gxhFKKagoS B63YbulZqDA6LoyPvLvzqoIqijCZtPnBDak80K7DQqTI4Uof8M3OyCAMwqPv44m3 3nMRa59WI0l5hm9Bcq76fsPcb0as3G3HY4UBpjiVwQoGVpStf1ErIUcPWSEhxiIu AwxTLSbEAGIJ7DAdR8ciG4ukP2vTFZgiEQGZlhNsr7QW0uxzS06xd5bqDzHvS8aD X7NGbM5PzhhwYagOBvkON2MknPYr+oHU+GNvMLCrj4LRSQ5H59fHyXCYeUvbHnIQ 7CpDk7jANmLHr2DoEY0YPQo2sN3dqiuefQ33fUz4bkdY1+NjDeqFIHMFIB3udjvA 1pxdFXn/MJISBoPwAKFrcJ6qIYVvX9qlle0anjLdlo9As2i1xUbJ/gJplb7nGSnw nrXni0Hw+DFYJwx/ofW1Q2w3a3OZwkqTLJOAWB2W9FYRw9/DsM54hr7MKjVy4cIY 7UEHj+k3kmGzQNKAX8c9tjXFSJCc1SZTBAbm781YJl6eCpUh0jQj9yYN5M8U3QIM Y8RZdeYAjRqd1LyAgdlG =UE3K -----END PGP SIGNATURE----- --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74ed7019-cb87-c55a-fb6d-1c016bf04d59>