Does HTTPS retrieval, among its other effects, sign a document?

Question

I'm asking in hopes of understanding in more specific details what TLS accomplishes.

I will try to elaborate my question, as follows.

Suppose Bob retrieves a document message.txt from Alice using HTTPS. In the course of this retrieval, Bob also stores into a zip file named packets.zip the relevant network communication (TCP packets, and similar) that Bob sees.

If Bob presents packets.zip to Dan, can Dan expect that with high probability Alice sent message.txt? By this I mean to ask, is packets.zip in effect a copy of message.txt that is cryptographically signed by Alice?
When Bob no longer has an open connection to Alice and Bob presents packets.zip to Dan, is Bob thereby revealing any secrets of Bob's or Alice's to Dan? I expect that Bob is not.
If packets.zip constitutes a signed copy of message.txt, when does the signature become invalid? Is it valid until and unless the relevant certificate is revoked?

Sort of. I have heard of "poor man's copyright" which meant mailing oneself a sealed envelope for the sake of getting a postmark. The intention was, if occasion would arise, to present the sealed postmarked document to a judge as evidence. (It turns out, that's not a good legal strategy.) In this question I am interested in how a mathematician would decide, not a judge. — ajm475du, Apr 11 '14 at 14:42
The document doesn't get signed. Only a small part of the handshake is signed, if at all. The rest of the connection is only protected by MACs, which can be forged by anybody who knows the shared key (at minimum the two end-points of the connection). — CodesInChaos, Apr 11 '14 at 14:43
Changed my words "take it as strong evidence" to "expect with high probability". That's a math question, no? — ajm475du, Apr 11 '14 at 14:45
Maybe my reading skills aren't what you'd like them to be, but I did read 20803. — ajm475du, Apr 11 '14 at 14:56
Encryption is predicated on a notion of high probability, is it not? I can lamely attempt an attack by sending 256K of random data and with some tiny probability, my victim's private key will decrypt it to a nice phishing message and hand over lots of money. One minus a tiny probability is a high probability. — ajm475du, Apr 11 '14 at 15:12

score 1 · Answer 1 · answered Apr 11 '14 at 15:12

HTTPS does not sign a document; it does not provide any lasting affidavit as to the provenance, legitimacy, or validity of the document.

A signature is a modification to or verifiable description of a document which can be used at a later time to validate the document or the fact of that document's authorship or review by an entity. As such, there must be some lasting effect to a signature - it needs to accompany the document itself as that document is passed on. HTTPS is merely a transport which does not alter or provide a lasting external validation of whatever it transfers.

Think of it in real world terms - it doesn't matter if I mail a document via USPS, FedEx, or pay a courier to hand-deliver it. Those are all just transport methods. If I forget to sign the document, none of these transports will add a meaningful signature to the document. Even if I had delivery confirmation, that just proves that the document arrived - it doesn't imply any signature or validation if I didn't attach those to the document before sending.

score 0 · Answer 2 · answered Apr 11 '14 at 14:49

0

As already mentioned in the comments, the HTTPS protocol does not sign a document. It merely uses the SSL/TLS protocol to encrypt and decrypt on the transport layer of the OSI model, by using a certificate (which contains the public key used to encrypt/decrypt data on clients) from the Public Key Infrastructure (PKI).

answered Apr 11 '14 at 14:49

Steven Volckaert

1,193
8
15

Is this not a signature? It sounds like encryption of the transport layer (OSI layer 4) employs Alice's private key, so that when decryption using Alice's public key succeeds, then Bob observes that Alice is the sender (insofar as Alice's key remains private). – ajm475du Apr 11 '14 at 14:53
IP address "signing" is of weak utility. If the "ownership" of the IP address comes into question, the whole signing scheme falls apart. Creative, but bad idea – makerofthings7 Apr 11 '14 at 14:56
@ajm475du: Not really. Someone could have stolen the certificate, and its private key, and set up a different web site. HTTPS only secures the data transport layer, and doesn't authenticate an identity. – Steven Volckaert Apr 11 '14 at 15:00
I'm not asking for biometrics, so like everyone else I must accept for the sake of argument that private keys stay private. – ajm475du Apr 12 '14 at 16:51

score 0 · Accepted Answer · answered Apr 11 '14 at 15:17

No, a SSL server does not sign what it returns. The operations which use asymmetric keys and may qualify as signatures occur during the initial steps of the connection (the "handshake"), before any applicative data is sent, so these operations cannot logically bind anybody to the contents of such applicative data.

There is a possible source of confusion, which must be dispelled: during the course of the connection usage, all applicative data will be covered by a MAC. It so happens that some sloppy but widespread documentations incorrectly refer to MAC as "signatures". However, they are not signatures, not in the sense of "opposable proof". In a MAC, the secret value needed to generate the MAC is identical to the value needed to verify the MAC; this implies that whoever can verify the MAC also has, by this fact, the power to forge the MAC. Thus, a MAC cannot be a "signature" in the sense that you want.

Given a copy of the server's certificate, which is trivial to obtain (by definition, the server sends it to any connecting client), it is easy to build from scratch all TCP packets and the complete connection records corresponding to a fake SSL connection that cannot be distinguished from a genuine connection. This is easily seen, mathematically, by looking at how the protocol works: with a simple RSA-based key exchange (the most common case), the client generates a random key (the "pre-master secret") and encrypts it with the server's public key. Only the server can do the decryption -- but the client also has that pre-master secret: he generated it ! It is thus trivial for the client to emulate all computations that the server would perform in that situation.

If a complete and undistinguishable fake connection, with arbitrarily chosen contents, can be built from scratch without even involving the server at all, any recorded trace of a connection cannot serve as signature in any way. Such a trace does not even prove that the SSL server actually exists at all.

Thanks for providing the counterexample that disproves the proposition that HTTPS signs a document. That's the way to impress me with an answer. It's ever so much more helpful than assertions, analogies, and recitations of definitions. Yes, folks, this counterexample is implied by the definitions, but implications can be difficult to derive or even impossible (undecidable). Thanks again. — ajm475du, Apr 12 '14 at 16:34

Does HTTPS retrieval, among its other effects, sign a document?

3 Answers3