• 15

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

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:

  1. At the Windows OS level? (the same subsystem that is administered by the Certificates mmc GUI and certutil etc.
  2. At the browser level? - for any major browser, especially Internet Explorer
  3. At the lowest possible level on Unix-like systems? (I assume this is OpenSSL but 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.

    • I know you said you're using IE, so I realize this won't be constructive for you, but could possibly be helpful to other users: When using Google Chrome browsers, you can quickly bypass the SSL warning without ever leaving the keyboard by simply typing the word danger. Also, in chrome://flags (from the address bar), you can choose to disable warnings [IIRC] from 30 to 90 days after they have been bypassed for each specific site on a one-off basis.

If you need security, then use SSL, and use it properly. If you do not need security, then don't use SSL.

Improper use of SSL harms more security, usability and availability than not using it at all.

The current browsers have finally strengthen the security and this is the normal evolution.

  • 5
Reply Report
      • 1
    • SSL is often the default protocol for many an open source project administration suite, Windows-based "role" service, etc.

There is no central place.

For Internet Explorer you might be able to hack some DLL and replace existing functionality. And you might need to do it for each version of windows you are using and keep it up-to-date after OS updates. hrome and Firefox have their own SSL stacks (NSS) which you would need to change. The situation is similar on Mac OS X where Safari is using one TLS stack and Chrome and Firefox are using their own TLS stacks (again NSS). And on UNIX system you mostly have to deal with Firefox and Chrome, which again use the NSS stack currently.

The efforts needed to hack all these places is probably more than the effort needed to add the custom CA you use for your test sites.

  • 3
Reply Report

You might be better off adding a transparent proxy that strips SSL, or creates matching certificates on the fly as a MITM style attack. That way, only one private CA is needed. This should be easy when using any provisioning system.

  • 2
Reply Report
      • 1
    • Ah okay, now we have an idea... I can see how to make that work going FROM the source TO the virtual machine I am using, but if I am stripping SSL or playing with the certificates, won't that make it impossible for the sender to handle the message on the other side when i send, say, some updated config values
      • 1
    • Well, thats what the transparent proxy is for, that's the one connecting to your SSL resource, while the lab is (unknowingly) using the proxy which takes the I/O and translates where needed.

Trending Tags