|
|
|
|
|
by _bxg1
2640 days ago
|
|
Interesting. Sounds like browser maintainers need to detect the patch level of a server and adjust the padlock icon accordingly. I don't know if this is as simple as a version number check, or if sites would need to be probed for vulnerabilities. In the latter case, maybe a global shared registry needs to be created that can be queried by browsers and updated by web admins (not on the honor system, obviously; after updating their server they could just ask it to re-audit them). Alternately, an HTTPS implementation that can silently update itself without admin permissions like browsers can. The web moves too fast for manual security patches. |
|
The client sends a list of acceptable cipher suites to the server. The server then selects one that is also agrees with (this can be based on many factors, strongest first, quickest first, a custom priority, etc). Because of this, if you send, say 40 ciphers, the server will only respond with one. To get an accurate list of cipher suites supported, you must send each one individually to truly test whether the server does support a particular cipher suite or not.
Not to mention, if a server is sending out its 'patch level' to a client machine on request, that in itself is a vulnerability.
The government does use such a tool - or at least something similar - https://pulse.cio.gov/ is just one example of a public repository of some of those results.