Cannot determine the certificate chain & trusted usages for a resumed SSL session

NEW
Unassigned

Status

()

P3
enhancement
8 years ago
a year ago

People

(Reporter: briansmith, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [psm-backlog])

Attachments

(2 attachments)

+++ This bug was initially created as a clone of Bug #651994 +++

This is very similar to to bug 650296 and 651994 and has a similar cause. When we resume a SSL session, we are relying on a trust decision that was made during the initial full handshake. But, we don't have a way, during the resumption, from extracting the actual validated certificate chain or usage trust information from the SSL session cache. We can't get that validated certificate chain from the SSL cache is because the libssl APIs do not provide a way for the certificate authentication callback to return the validated chain and/or to save application-specific data in the SSL session cache.

Comment 1

8 years ago
Created attachment 527888 [details] [diff] [review]
Cache peer's certificate chain in session ID

Cache the peer's intermediate CA certificates in session ID, so that
they're available when we resume a session.

The certificates are the ones in the SSL Certificate message.

Comment 2

8 years ago
Created attachment 527889 [details] [diff] [review]
Add the SSL_PeerCertificateChain function

The certificate authentication callback is given the SSL
socket 'fd'.  Pass 'fd' to SSL_PeerCertificateChain to get
the certificate chain in the peer's Certificate message.
Whiteboard: [psm-backlog]
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.