I understand why SSL warnings are needed and why users, even experienced ones, should be prevented from easily ignoring them. I also understand that in general, the "white list" or trusted untrustworthy root CA approach is the best approach when working on your everyday workstation that you also do banking or trading or emailing on.
That said, if I am using
Internet Explorer 8 on a freshly-provisioned test box that has no access to the Internet, it serves no purpose for me to have to click one or two buttons constantly to manage a server at
https://my-vm-213.goofy.local or whatever the case may be. And if we're dealing with hosts that are going to go up and down and sideways in large numbers, it makes no sense for me to spend a moment adding root CA's that are stupid to add and won't have a reason to exist within hours.
My question is this: is there a way to "always pass" SSL checks:
- At the Windows OS level? (the same subsystem that is administered by the
- At the browser level? - for any major browser, especially
- At the lowest possible level on Unix-like systems? (I assume this is
OpenSSLbut I don't really know)
To me this would be something like:
( X ) Always validate SSL certificates (DANGEROUS!)
More rationalization below
If you know that you are working in a lab environment or newly-provisioned environment or small business environment, strictly on systems-related matters, there is no benefit in terms of confidentiality or integrity (or awareness of the lack thereof) when you always suppress SSL warnings because you already know that they are going to appear. I suppose you could argue, "well, what if somebody knows that you are so lax about this and exploits it by specifically targeting those kinds of hosts you are looking to suppress," but that argument only holds if a) there is any obvious means of exploiting your testing of IE8 browser compatibility for an Intranet app, b) you have misconfigured your virtual machine networking and actually allowed it to transmit or receive packets through its gateway, and other reasons, but most importantly, c) you have ever done anything differently as a result of that warning while working on a host you know will produce that warning.