First, I have some conceptual questions, and then some more specific questions with regards to implementing HTTPS.

  1. In an extremely simple system with only 2 hosts (A and B) talking on a LAN but an active MITM on the the LAN (Z), who is active from the very beginning and able to intercept and fully modify first connections between the 2 hosts A and B, it is true that fundamentally, some piece of data must be shared out-of-band to avoid this attack scenario, correct?

    In other words: there is no algorithm, protocol, or mathemagical trick that exists that would allow host A to connect to B for the first time ever, having absolutely no prior knowledge of B, and somehow assert that B is not a MITM, correct? I know this question might sound obvious, because truthfully if A has no knowledge of B whatsoever, then there really is nothing distinguishing B from Z to A, but I need to hear it from the experts.

  2. This is exactly how PKI on the internet works, right? Because a server's certificate is signed by a CA's private key, but the public certificate of the CA was effectively shared beforehand, and in an out-of-band manner (when you purchased the computer, or OS disc, it was already in the browser software).

  3. Is it also true that a CA issued cert in comparison to a self-signed cert only provides a logistical benefit in the form of scalability? (in comparison to a hypothetical world where all parties shared certs securely, out-of-band) In other words say every site on the internet attempted to use self-signed certs, then technically it could still be secure if for example amazon.com and I communicated out of band and amazon shared its certificate (in a way that I could establish trust that the provided cert was actually amazon's), so I could validate future connections, right? But the problem would be needing to perform this out-of-band step for every website out there.

Now onto a related implementation problem.

Picture a hypothetical self-contained computer system with roughly 100 hosts on a private LAN. 1 host is the "master", and is initially installed manually (from a disc, drive, or some other trusted physical media). But the remaining 99 hosts are installed over the LAN (https). If the remaining 99 hosts have no persistent storage and install directly into RAM and begin executing, then it must be impossible to design such a system to avoid the initial MITM possibility described above, right? Especially considering each of the 99 hosts does a full re-install, and essentially connects for the first time on every reboot. Because there is no place or means to store any kind of pre-shared certificate or validation data so that the 99 clients can digitally verify an SSL certificate presented by the "master" server. And if there is no out-of-band method of communication, then they must resort solely to initially accepting the certificate over the same connection (creating the MITM possibility). Additionally, the 99 hosts are automated, so there is no possibility for a user to intervene, and validate a fingerprint, like with what SSH does. But this would really just be another form of out-of-band communication it seems.

  • I think you need to re-read the basics of TLS. You've missed how PKI actually works and how certificates are used. – schroeder Nov 24 '16 at 7:41
  • And how is that? According to tools.ietf.org/html/rfc5246#page-16, on pages 35 and 36, after the ClientHello, the server sends its certificate to the client to be authenticated. And according to ibm.com/support/knowledgecenter/SSFKSJ_7.1.0/com.ibm.mq.doc/…, there are 4 aspects to certificate verification. 1) The digital signature is checked 2) The certificate chain is checked 3) Expiry/activation dates checked 4) Revocation status checked. For step1), the digital signature in the server's certificate is validated with the CA's public key in the CA cert, correct? – krb686 Nov 24 '16 at 14:52
  • And concerning distribution, for example security.stackexchange.com/questions/17656/… the top voted answer says "Browsers and/or operating systems tend to come with a pre-defined list of CA certificates used as trust anchors to check the certificates of servers they connect to." Which part is incorrect/missing? – krb686 Nov 24 '16 at 14:57
  • Also, this mathematician/programmer has a page - michael.orlitzky.com/articles/… - which explains: "With a CA-signed certificate, there is also exactly one opportunity for a man in the middle attack to occur....If your browser came with your PC, that's an opportunity for a MITM attack. Acer, or HP, or whoever could easily have replaced all of your certificates with phony ones...This attack need not be physical, as there are plenty of examples of PCs shipping with malware on them." – krb686 Nov 24 '16 at 15:04

For the points 1..3:
Yes, that's how it works. There is some initial trust needed, either in the form of a trusted CA which can be used to derive trust into leaf certificates or as directly trusted shared leaf certificates.

As for your implementation problem:
I assume that your disc less clients have same sort of read-only medium they boot from because otherwise your trust problem starts earlier, i.e. how they make sure that they boot the correct OS when booting from a network. Thus assuming that the OS they boot is in fact the correct one but that they have no knowledge of who they can trust they have to rely on "TOFU", i.e. Trust On First Use.

Of course one could try to put at least some initial trust information in the systems because even weak trust might be better than no trust. For example each of these system could come with a different certificate installed by the manufacture, all signed by the manufactures CA. This way one could kind of assure on first connect that the peer device is at least from the manufacture and thus make attacks harder. This is not foolproof of course since the attacker might be able extract the device certificate and key from an existing device or modify such device to work as MITM but this way the initial costs of the attack would be higher.

BTW, this is not a problem restricted to TLS or even to computers but it is a simple question of what information are needed to trust somebody. And if you have no information at all you have no way to decide if communication peer is trusted or not. That's the reason you have various forms of centrally issued identification in real life, i.e. passports, driver license or similar which provide you with a way to derive trust because you somehow trust the issuers of these ID cards.

  • To clarify some points that I probably should put in the original question - the 99 diskless clients contain TPMs, and perform a trusted boot. They use the SRTM and DRTM (tboot). They actually boot with PXE first, and then use HTTPS later. So they have the capability to measure images that come over PXE, though it seems to me there is still no way to securely devise HTTPS without storing some certificate on say, TPM nvram beforehand that would persist across reboots. From what I've read, it seems even remote attestation requires stored AIK certs that are CA signed – krb686 Nov 24 '16 at 6:08
  • @krb686: If you have control over the trusted boot process by having the ability to sign your own boot images you could add the needed trust (i.e. the trusted CA) to the boot images provided on the network. – Steffen Ullrich Nov 24 '16 at 6:13
  • That's an interesting point. I considered the idea of adding the master server's ssl cert into one of the boot images which would then get hashed as part of tboot process, but not signing. I guess I'm not clear on how I would use that, or tie it back to some TPM enforcement mechanism. Ultimately I would think it would need to somehow be tied to PCRs on the TPM for the TPM to enforce anything, but I only know how to do that in relation to nvram, sealed keys, and so on. I guess the attestation of the PCRs to the master seems like the issue to me. Maybe a good topic for another question – krb686 Nov 24 '16 at 6:24

Your Answer

