You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2020. It is now read-only.
Not sure whether this is really a pulse issue or a pshtt issue...
Example: sdv.max.gov supports HTTP and HTTPS. All HTTP is redirected to HTTPS. But HTTPS requires client cert authentication, so without a valid client cert the SSL handshake will always fail.
pshtt returns these values:
Defaults to HTTPS: False
Strictly Forces HTTPS: False
Domain Supports HTTPS: False
Domain Enforces HTTPS: False
Pulse shows:
Compliant with M-15-13 and BOD 18-01: No
Enforces HTTPS: No
I think it is arguable whether these pshtt return values are appropriate in this case, but either way the pulse status is clearly not appropriate.
The text was updated successfully, but these errors were encountered:
@PaulSD Good find! I agree that we should definitely be able to detect and support client authentication, and I believe this should happen at the pshtt level.
I'll leave this open until we've resolved the Pulse display issue one way or another, but moving all substantive discussion on resolution to cisagov/pshtt#153.
Not sure whether this is really a pulse issue or a pshtt issue...
Example: sdv.max.gov supports HTTP and HTTPS. All HTTP is redirected to HTTPS. But HTTPS requires client cert authentication, so without a valid client cert the SSL handshake will always fail.
pshtt returns these values:
Defaults to HTTPS: False
Strictly Forces HTTPS: False
Domain Supports HTTPS: False
Domain Enforces HTTPS: False
Pulse shows:
Compliant with M-15-13 and BOD 18-01: No
Enforces HTTPS: No
I think it is arguable whether these pshtt return values are appropriate in this case, but either way the pulse status is clearly not appropriate.
The text was updated successfully, but these errors were encountered: