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
It is difficult for a customer to determine the safety of changing security policies. It is difficult for them to figure out which capabilities they might be removing without manual inspection of the security policies.
Solution:
s2n-tls should document this information.
One potential solution is to make a "compatibility matrix" of all the possible security policy transitions.
Note: I'm make up capabilities, the proposed examples may not have accurate text, and are for UI demonstration only.
default
default_tls13
20230317
default
DANGER
DANGER
default_tls13
DANGER
BREAK
20230317
DANGER
SAFE
The left column is the old policy, and the top row is the new policy. The table can be read as follows.
Moving from 20230317 to default_tls13 is SAFE, because 20230317 is a subset of default_tls13
Moving from default to default_tls13 is full of DANGER, but their have no overlap in compatible versions.
Ideally this table would include links to the actual capability differences between policies, which would let customers know that moving from default_tls13 to 20230317 would break customers using SHA1 digests in their signatures.
I would vote for this information being hosted in a simple static site.
The text was updated successfully, but these errors were encountered:
Problem:
It is difficult for a customer to determine the safety of changing security policies. It is difficult for them to figure out which capabilities they might be removing without manual inspection of the security policies.
Solution:
s2n-tls should document this information.
One potential solution is to make a "compatibility matrix" of all the possible security policy transitions.
Note: I'm make up capabilities, the proposed examples may not have accurate text, and are for UI demonstration only.
The left column is the old policy, and the top row is the new policy. The table can be read as follows.
Ideally this table would include links to the actual capability differences between policies, which would let customers know that moving from default_tls13 to 20230317 would break customers using SHA1 digests in their signatures.
I would vote for this information being hosted in a simple static site.
The text was updated successfully, but these errors were encountered: