Can a website check in the application layer which key/certificate the client is using?
Somehow detect that the certificate is not the real one, but issued by Sneakycorp Inc. because a man-in-the-middle attack is in progress.
I realize that the mitm could fake the response, but that raises the bar for simple copying proxies.
I see two possibilities:
Use code on client side
Use code on client side (e.g. JavaScript) to read the used certificate and send the info back to the server. Then on server side you could compare if the used certificate is the expected one.
It seems like in JavaScript it is not that easy to get the necessary info on the certificate. The used method in the linked answer seems to be Firefox only at the moment.
TLS fingerprinting
A second way is used by large content delivery sites: HTTPS fingerprinting
Based on the TLS headers you can generate a fingerprint on TLS stack and often also on the used technology/run-time and OS like .Net, Java, Python, and so on. If you then compare that with what you expect e.g. based on the user agent you can calculate the chance that you have a direct connection or if some man-in-the-middle server is active.
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
In the beginning of an SSL query, the client sends a CLIENT_HELLO message.
The server replies with a certificate message that gives the chain of verifications going back to a known trusted agent.
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Under what circumstances can certfiicates be revoked? I am trying to understand why SSL sends the certificate each time -- it seems really wasteful, but there is probably a good reason.
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server? It seems like one could at least send less data across the network
TLS Certificate message after `ServerHello is mandatory in mostly cases, so caching won't have any useful effect. See RFC5246
7.4.2. Server Certificate
When this message will be sent:
The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message.
TLS has its own methods to improve performance. When client sends a valid session_id in ClientHello the session can be resumed and the parties must proceed directly to the Finished messages
Also RFC5077 specifies how to resume sessions without server-side state
EDITED - added comments to specific questions
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
"always" is not correct. TLS sends certificates during handshake. Once the shared key is negotiated, the session can be resumed later by client using sessionid (the usual behaviour). Then, the server does not send the certification chain.
The server sends the certification chain. The client must verify that the presented certificate is reliable:
checking a digital signature performed with the private key of the server certificat
the certificate is issued by a trusted CA. Is supposed that client has a trust store with the root certificates of the certification authorities it trust. The client builds the certification chain presented by server until it finds the root certificate in local truststore
You can perfectly skip the sending of certificates from the server in the second step step if client has a copy of the server certificate in a local truststore
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
In this scenario the attacker could make a MITM attack. The certificate must be revoked by CA and client should check revocation. This is out of scope of TLS
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Seems in this case the certificate is the least of the problems...
Under what circumstances can certfiicates be revoked?
Each CA stablish its own procedure. There is no a standard but there are "good practices": When certificate data changes (e.g email) or becomes invalid (Representative of a company), after a renewal revoke the older one, when key is compromised or certificate is lost
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server?
Yes it is possible as commented above: Verify a digital signature, verify revocation and stablish a refreshing mechanism
But if you're looking for performance comparing with TLS, the session resumption will probably have better results
For the purposes of secrecy and authenticity of communications I use SSL / TLS (https) with client certificate. If I log the entire SSL traffic on the server side, is the SSL log sufficient evidence that the communication between the server and the other side with client certificate was exactly as it is recorded in the log? At the beginning an asymmetric handshake is used but further communication continues with symmetric encryption. Symmetric encryption would not mind if one of the messages cannot be forged on the receiving side. As a server I know the symmetric key so it should be able for me to spoof one of the messages sent by the client, shouldn't it? What algorithm and what special settings shall I use, so that client could not say that he sent a different message than what I recorded in the log?
Logging anything (including data from SSL) does not proof the origin of the data. In theory you've could made up the data yourself. Even logging the complete SSL traffic including the necessary encryption key does not proof anything because in most cases this could have been made up too.
It might be acceptable as a proof if the whole SSL traffic is logged including the encryption key and if a client certificate was used for authentication (i.e. two-way SSL). The real client certificate owned by the client is a part you can not make up yourself. But there is still no guarantee that some judge would accept it as proof. And of course the client could try to deny that this is its own client certificate which was used.
I work at company X and we want to engage in a B2B transaction with company Y. In doing so, Y is requiring client side authentication; they already provide server-side authentication - so this would be a mutual SSL transaction.
My understanding is that I simply need to provide my CA-signed cert as part of my client side HTTPS communication. In doing so, asymmetric cryptographic guarantees (i.e., public/private key technology) ensures that I am who I claim I am - in effect, it is not possible to impersonate me. (the root CA has ensured I am who I am, that is why they signed my cert, and it's possible to prove that I didn't "manufacture" the certificate).
Here's my question: is this all I need to provide company Y?
Alternatively, do I have to provide them with another key in advance, so that they can ensure I am not a rogue who happens to have "gotten a hold" of a root-signed certificate for me (company X)? It would seem that if one has to provide this extra key to all parties he wishes to engage with on the client side, it would seem to make client-side SSL not as scalable as server-side SSL. My guess is that it's not possible for one to "get a hold" of a client side cert; that the actual transmission of the client side cert is further encoded by some state of the transaction (which is not reverse-engineerable, feasibly).
Does this make sense and am I right or am I wrong? If I'm wrong, does Y in effect need to get an "extra" pre-communication key from every party that connects to it? (which they want to verify)?
Thanks.
===
Thanks for the responses below, at least the first two have been helpful so far (others may arrive later).
Let me talk in a bit more detail about my technical concern.
Suppose company Y attempts to "re-use" my client side cert to impersonate me in another client-side transaction with another company (say "Z"). Is this even possible? I am thinking - again, perhaps poorly stated - that some part of the transmission of the client side certificate prevents the entire key from being compromised, i.e., that is not technically feasible to "re-use" a client certificate received because you could not (feasibly) reverse engineer the communication which communicate the client cert.
If this is not the case, couldn't Y re-use the cert, impersonating X when communicating (client-side) to Z?
ps: I realize that security is never 100%, just trying to understand what is technically feasible here and what is not.
Thanks very much!
===
Further technical details, I appreciate any additional input very much - this has been very quite helpful.
From a layman's point of view, my concern is that when a client sends his client cert, what is he sending? Well, he has to encrypt that cert using his private key. He sends the ciphertext with the public key, and then a receiving party can use that public key to decrypt the private-key-encoded payload, right? That makes sense, but then I wonder -- what prevents someone from hearing that communication and simply re-using the private key encoded payload in a replay attack. Just replay the exact ones and zeroes sent.
Here's what I believe prevents that -- it can be found in the TLS RFC, in multiple places, but for example in F.1.1:
F.1.1. Authentication and key exchange
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the server is authenticated, the channel is
secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked.
The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the
master_secret (see Section 8.1). The master_secret is required to
generate the certificate verify and finished messages, encryption
keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
a correct finished message, parties thus prove that they know the
correct pre_master_secret.
I believe it's the randomization associated with the session that prevents these replay attacks.
Sound right or am I confusing things further?
As long as you keep the private key safe (and the CA keeps their signing key safe), "company Y" doesn't need any other information to authenticate you. In other words, they can be sure that a request really came from the subject named in the certificate.
However, this doesn't mean that you are authorized to do anything. In practice, most systems that use client certificates have an "out of band" process where you provide the "subject" distinguished name that is specified in the client certificate, and the system assigns some privileges to that name.
In fact, because of some practical limitations, some systems actually associate the privileges with the certificate itself (using the issuer's name and the certificate serial number). This means that if you get a new certificate, you might have to re-enroll it, even if it has the same subject name.
A certificate only assures a relying party you have a certain name. That party needs some additional mechanism to determine what you are allowed to do.
Unlike authentication mechanisms based on "secret" (symmetric) keys—e.g., passwords—a server only needs public information for asymmetric authentication. A private signing key should never be disclosed; it's certainly not necessary for client authentication.
With symmetric, password-based authentication, the client and server get access to the same string of bytes—the secret key. With public-key cryptography, only the public key of a key pair is disclosed. The corresponding private key is never disclosed, and no practical method for figuring out the private key from the public key has been discovered.
As long as you keep your private key safe, the server at company Y cannot forge requests that appear to come from you.
Client authentication replay attacks are defeated by requiring the client to digitally sign a message that includes a number randomly generated by the server for each handshake (this is the "random" member of the "ServerHello" message). If the packet used to authenticate the client in a previous session were re-used, a server will be unable to verify the signature, and won't authenticate the replay attack.
RFC 2246, Appendix F.1.1.2 might be a more helpful reference—especially the third paragraph:
When RSA is used for key exchange, clients are authenticated using
the certificate verify message (see Section 7.4.8). The client signs
a value derived from the master_secret and all preceding handshake
messages. These handshake messages include the server certificate,
which binds the signature to the server, and ServerHello.random,
which binds the signature to the current handshake process.
Your client-side certificate (or more precisely its private key), is only as secure as your company's online and/or physical security let it be.
For extremely secure relations (which typically do not have the requirement of scaling much), it may be acceptable that the provider of the service requires an extra element in the protocol which allows them to identify your site (and more often than not, to identify a particular computer or individual within the company, which is something client certs do not fully do.)
This of course brings the question: what is warranty that this extra bit of authentication device will be more securely held by your company? (as compared to the client-site certificate itself). The standard response for this is that these extra bits of security elements are typically non-standards, possibly associated with physical devices, machine IDs and such, and are therefore less easily transportable (and the know-how about these is less common: hackers know what RSA files to look for, and what they look like, what do they know of the genesis and usage of the KBD-4.hex file ?)
Extra question: Can Y make use of my client-side certificate elsewhere?
No they [normally] cannot! The integrity of this certificate lies in your safe keeping of its private key (and, yes, a similar safekeeping from the certificate providers...). Therefore, unless they are responsible for installing the said certificate, or unless their software on your client (if any) somehow "hacks" into certificate-related storage / files / system dlls, they should not be able to reuse the certificate. That is they cannot reuse the certificate any more easily (which is theoretically NP hard) than anyone that, say, would sniff the packets related to authentication as the client establishes a session with the Y site.
Extra questionS ;-)
- What is the nature of the client cert?
- Man-in-the-middle concerns...
Before getting to these, let's clear a few things up...
The question seems to imply TLS (Transport Layer Security) which is indeed a good protocol for this purpose, but for sake of understanding, the keys (public and private) from the certs (server's and client's) could well be used with alternative protocols. And also, TLS itself offers several different possible encryption algorithms for its support (one of the initial phases of a TLS session is for both parties to negotiate the set of algorithms they'll effectively use).
Also, what goes without saying... (also goes if you say it): the respective private keys are NEVER transmitted in any fashion, encoded or not. The confusion sometimes arise because after the authentication phase, the parties exchange a key (typically for a symmetric cipher) that is used in subsequent exchanges. This key is typically randomly generated, and of totally different nature than the RSA keys whether public or private!
In a simplified fashion, the client's certificate contains the following information:
- The Certificate Authority (CA aka issuer)
- The "owner" of the certificate (aka Subject)
- Validity date range
- the PUBLIC key of the certificate
In more detail, the certificates are typically found in an X.509 wrapper (? envelope), which contains additional fields such as version number, algorithm used, certificate ID, a certificate signature (very important to ensure that the certificate received wasn't tempered with). The X.509 also provide for optional attributes, and is also used for transmitting other types of certificate-related data (such as the CRL)
Therefore the certificate's content allow the recipient to:
- ensure the certificate itself was not tempered with
- ensure that the issuer of the certificate is one accepted by the recipient
- ensure that the certificate is valid/current and not revoked
- know the public key and its underlying size and algorithm
With regards to man-in-the-middle concerns, in particular the possibility of "re-playing" a possibly recorded packet exchange from a previous session.
The protocol uses variable, possibly random MACs (Message Authentication Codes) for that purpose. Essentially, during the negotiation phase, one of the parties (not sure which, may vary...) produces a random string of sorts and sends it to the other party. This random value is then used, as-is (or, typically, with some extra processing by an algorithm known by both parties) as part of the messages sent. It being encoded with the private key of teh sending party, if the the receiving party can decode it (with sender's public key) and recognize the (again variable) MAC, then it is proof that the sender is in possession of the private key of the certificate, and hence its identity is asserted. Because the MACs vary each time, pre-recorded sessions are of no help (for this simple purpose).