18

I am new to security work and I am implementing someone else's design. The design calls for a TCP server with TLS in an environment where there is no DNS - only IPs.

I am working with a typical certificate chain (Self-signed Root cert -> Intermediate cert -> Endpoint cert). The TCP server presents the Endpoint cert to a client which has the public portion of the Intermediate cert pinned in its code. When the client connects, it will check that the Intermediate cert was used to sign the Endpoint cert.

So as I understand it, when the client connects, a key exchange occurs to secure the communication and the client then uses the certificate chain verification to verify that the server really is who it says it is. However, in this scheme, couldn't an impostor just present the certificate after getting it from the real server?

Am I misunderstanding this as a flaw? From my understanding, without DNS names to tie the certificate to, checking the chain (with pinned signed parent certificate or not) is not sufficient. Can anything else be done here?

Improve this question
8
  • 8
    They're flawed in that they're not a great idea, but not in that they're insecure. A cert with an IP address in the SAN is no less secure than a cert with a DNS name in the SAN. The authentication process is the same. What specifically are you thinking is different? I can't tell exactly from the question as currently formed.
    – Xander
    Commented Aug 7, 2019 at 3:22
  • 10
    They can't because they don't have the private keys. It's not any different for a certificate for an IP address vs a certificate for a DNS name however, which may be what's confusing me.
    – Xander
    Commented Aug 7, 2019 at 3:28
  • 1
    No , I get it now, your comments, in conjunction with @gowenfawr's answer - it's making sense now. Thanks!
    – Matt
    Commented Aug 7, 2019 at 3:30
  • 2
    Note that 1.1.1.1 has such a setup exposed to the public internet. Since Cloudflare is not completely incompetent (the occasional security problem notwithstanding), whatever security risks may exist are probably surmountable.
    – Kevin
    Commented Aug 7, 2019 at 17:20
  • 2
    Note that you use "CA" where you mean "certificate".
    – jcaron
    Commented Aug 8, 2019 at 11:11

3 Answers 3

Reset to default
46

However, in this scheme, couldn't an impostor just present the certificate after getting it from the real server?

An impostor cannot present, and take advantage of, the real server's certificate unless it also has the matching private key. This is true whether the SAN DNS entry or IP entry are used to identify the certificate being presented.

Improve this answer
5

When the attacker sends the server's certificate, the client will encrypt a shared secret (used to generate the symmetric encryption key for the session) with the public key of that certificate. The attacker will then be unable to recover the secret since they don't have the certificate's private key, so they won't be able to complete the TLS handshake.

Improve this answer
2
  • 3
    Only in some cipher suites. However when the attacker sends the certificate he also has to send a CertificateVerify message signed by the private key, which he doesn't have so cannot implement.
    – user207421
    Commented Aug 7, 2019 at 23:37
  • @user207421: through TLS1.2 except for plain-RSA (akRSA) server does sign, but within the ServerKX message not a separate CertVerify message. Client does use separate CertVerify if it auths at all. In 1.3 server does use CertVerify, but plain-RSA is never used.
    – dave_thompson_085
    Commented Aug 8, 2019 at 7:01
2

For inspiration, look at how SSH key exchange works:

The client maintains a table of "known servers" that matches an IP address to a hash. When connecting to a server, the client receives the server certificate (public key) and computes the hash of it, and looks up the server's IP address in the "known servers" table.

If the client has seen this server before, it can compare the computed hash of the certificate with the one it has recorded for the server. If they match, then everything is fine and the connection continues. Otherwise, the SSH program will throw up a big warning message and refuse to connect.

When the client connects to a server for the first time, the user is notified that we haven't seen this server before, and offers to add the server's certificate to it's known servers table. This step can be bypassed by manually entering the server's certificate details in the known servers table.

Improve this answer
6
  • 4
    You write "server certificate (public key)" as if they are the same thing. They are not, but this may be what confused you into thinking SSH is applicable to the discussion. A certificate must have countersignatures in addition to the public key. These signatures form a chain back to trust root (or not), which creates the possibility of automatically making a correct trust decision on a certificate that's never been seen before... something not possible with standalone keys.
    – Ben Voigt
    Commented Aug 8, 2019 at 3:54
  • Also nits: OpenSSH, the dominant implementation, stores the full pubkey in 'known_hosts', although to the user it displays only the fingerprint which is a hash. Also it stores both hostname and IPaddr when available and matches on either, so you can have a host that has multiple IPs or changes IPs over time, and you can have an IP with multiple names or changing names.
    – dave_thompson_085
    Commented Aug 8, 2019 at 7:05
  • @BenVoigt I agree that this approach does not utilize a chain of trust for the server certificates. I'm more or less proposing an approach that can be used when a full chain of trust can't be used for some reason, but lets you still utilize a large portion of the existing TLS libraries and frameworks available (such as OpenSSL)
    – Paul Belanger
    Commented Aug 8, 2019 at 12:10
  • How is this relevant to the discussion of whether TLS is broken when using IP addresses?
    – Boris the Spider
    Commented Aug 8, 2019 at 15:05
  • it's an example of how TLS can be utilized when no DNS information is available for certificate validation, as an alternative to chain-of-trust.
    – Paul Belanger
    Commented Aug 8, 2019 at 15:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .