Add client-side SCT verification and entry matching in hammer - #897
Conversation
Update hammer's httpWriter to parse and cryptographically verify AddChainResponse signatures against the log's public key. Reconstruct the CertificateTimestamp from the submitted certificate and verify that the LogID, timestamp, and certificate fields in the returned SCT match the request. Refactor base64 public key extraction into parseLogPublicKeyB64 helper function and reuse it inside logSigVerifier. Implement newAddChainResponseVerifier factory constructor, decoupling HTTP transport from verification logic. Precompute expected Log ID outside verification callback closure to eliminate redundant public key marshaling and SHA-256 computation in the hot path. Pre-allocate chainCerts slice with exact len(req.Chain) capacity and decode response extensions from base64 exactly once into extBytes (parsing via staticct.ParseCTExtensionsBytes) to eliminate redundant allocations and decoding. Ensure verification fails explicitly if public key is nil or request payload is empty, and format verifyWriteResponse error in httpWriter to include verification failure details and readable body string (%q). Export IsPrecertificate in x509util, call x509util.IsPrecertificate directly across chain_validation and hammer without wrappers, and use staticct.NewCertificateTimestamp helper to cleanly construct sctInput. TAG=agy CONV=fdd8e21c-6548-461f-8ead-5ec8915de98d
|
Gentle ping on that one, I'd like to get it in to close on #884. |
| pubBytes, err := x509.MarshalPKIXPublicKey(pubKey) | ||
| if err != nil { | ||
| return 0, 0, fmt.Errorf("can't parse extensions: %v", err) | ||
| return func(reqBytes []byte, respBytes []byte) (uint64, uint64, error) { |
There was a problem hiding this comment.
It feels like at this point we know the user intent is to verify (they've provided a "pub key"), but the key is broken so we should bail rather than return a func which will always error out.
Could perhaps return (func..., error), and just check the err from main rather than inlining in a chained call?
There was a problem hiding this comment.
Nice, thanks! I've also added the same check when the key is nil, at which point, you might as well not call the function if your intent it actually to have a nil key.
| case *rsa.PublicKey: | ||
| if err := rsa.VerifyPKCS1v15(pk, crypto.SHA256, digest[:], ds.Signature); err != nil { | ||
| return 0, 0, fmt.Errorf("SCT RSA signature verification failed: %w", err) | ||
| } |
There was a problem hiding this comment.
can probably safely ditch this RSA support and rely on the default "computer says no"?
Pretty sure there are no RSA static CT logs and never should there be :)
This PR allows the hammer to verify that the SCTs it receives matches with the requests it sent.
While I'm there, move
isPrecertificatetox509util.I tested this with the hammer locally and it worked. I'll send a PR afterwards that adds instructions to run the hammer locally with a POSIX log unless someone can point me at them!
Fixes #884.