SSL and IE8

[Proxus]

I apologize if this question has been answered before but I did a search and could not find a repeat of this specific problem.

I am currently converting our web page to use SSL and the process has been pretty straight forward so far. I was doing some testing and I encountered a rather annoying problem. It seems that even though my merged certificate will load fine and properly allow our web server to serve SSL pages to Firefox, IE8 will always return a "Internet Explorer cannot display the webpage". Is there a particular step I may have overlooked in this process?

My IE8 will access other SSL web pages just fine so I don't think browser settings are the problem.

Any ideas?

[Bruce]

Nothing springs to mind.
Is the site online? Can I acces it from here?

[Proxus]

It is unfortunately not online. I've been using the hosts file to point to my internal IP(we're operating behind a firewall).

I did some further testing and found that it seems that only Firefox on my machine can connect to the web server, other machines on our network cannot connect with IE8 or FF.

I can't seem to figure out why my firefox is so "special" in this matter, I dug through all of the settings and I can't find anything in particular that would differentiate what it is capable of accessing vs. the other browsers.

I'm also looking into a way to get you access to the web sever to take a look at what's going wrong but that might take awhile here

[Proxus]

After much poking and prodding I discovered that the problem was with the level of encryption that the SSL Certificate was using.

IE8 running on a Windows XP machine can only support up to RC4-128 encryption while our certificate was using AES-256.

[Proxus]

Again I apologize if this is posted elsewhere but I did find that there is a SSLCertificateOptions item for RemoveCertificateAlgorithm but I can't seem to find what this is/should be set to and if it will restrict the webserver to RC4-128 or not.

[Bruce]

not sure if it helps, but perhaps read this;
http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=1023.0

>> IE8 running on a Windows XP machine can only support up to RC4-128 encryption while our certificate was using AES-256.

What country are you running in? I would be enormously surprised if IE8 on any platform only did SSL2 not SSL3. Perhaps start by running the the SSLScan test mentioned in the link above on your XP machine and post the results here.

Cheers
Bruce

[Proxus]

Here's a link I found on browser compatibility.
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=SO12413&actp=search&viewlocale=en_US&searchid=1309367283959

Internet Explorer 8    Windows XP    RC4-128-bit

To answer your post:
Running in USA:
Microsoft Windows XP
Professional
Version 2002
Service Pack 3

First SSLScan test results:
Testing SSL server <redacted> on port 443

  Supported Server Cipher(s):
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA

  Prefered Server Cipher(s):
    SSLv3  256 bits  AES256-SHA

Second SSLScan test results:
Testing SSL server <redacted> on port 443

  Supported Server Cipher(s):
    Failed    SSLv2  168 bits  DES-CBC3-MD5
    Failed    SSLv2   56 bits  DES-CBC-MD5
    Failed    SSLv2  128 bits  IDEA-CBC-MD5
    Failed    SSLv2   40 bits  EXP-RC2-CBC-MD5
    Failed    SSLv2  128 bits  RC2-CBC-MD5
    Failed    SSLv2   40 bits  EXP-RC4-MD5
    Failed    SSLv2  128 bits  RC4-MD5
    Rejected  SSLv3  256 bits  ADH-AES256-SHA
    Rejected  SSLv3  256 bits  DHE-RSA-AES256-SHA
    Rejected  SSLv3  256 bits  DHE-DSS-AES256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Rejected  SSLv3  128 bits  ADH-AES128-SHA
    Rejected  SSLv3  128 bits  DHE-RSA-AES128-SHA
    Rejected  SSLv3  128 bits  DHE-DSS-AES128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Rejected  SSLv3  168 bits  ADH-DES-CBC3-SHA
    Rejected  SSLv3   56 bits  ADH-DES-CBC-SHA
    Rejected  SSLv3   40 bits  EXP-ADH-DES-CBC-SHA
    Rejected  SSLv3  128 bits  ADH-RC4-MD5
    Rejected  SSLv3   40 bits  EXP-ADH-RC4-MD5
    Rejected  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
    Rejected  SSLv3   56 bits  EDH-RSA-DES-CBC-SHA
    Rejected  SSLv3   40 bits  EXP-EDH-RSA-DES-CBC-SHA
    Rejected  SSLv3  168 bits  EDH-DSS-DES-CBC3-SHA
    Rejected  SSLv3   56 bits  EDH-DSS-DES-CBC-SHA
    Rejected  SSLv3   40 bits  EXP-EDH-DSS-DES-CBC-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Rejected  SSLv3   56 bits  DES-CBC-SHA
    Rejected  SSLv3   40 bits  EXP-DES-CBC-SHA
    Rejected  SSLv3  128 bits  IDEA-CBC-SHA
    Rejected  SSLv3   40 bits  EXP-RC2-CBC-MD5
    Rejected  SSLv3  128 bits  RC4-SHA
    Rejected  SSLv3  128 bits  RC4-MD5
    Rejected  SSLv3   40 bits  EXP-RC4-MD5
    Rejected  SSLv3    0 bits  NULL-SHA
    Rejected  SSLv3    0 bits  NULL-MD5
    Failed    TLSv1  256 bits  ADH-AES256-SHA
    Failed    TLSv1  256 bits  DHE-RSA-AES256-SHA
    Failed    TLSv1  256 bits  DHE-DSS-AES256-SHA
    Failed    TLSv1  256 bits  AES256-SHA
    Failed    TLSv1  128 bits  ADH-AES128-SHA
    Failed    TLSv1  128 bits  DHE-RSA-AES128-SHA
    Failed    TLSv1  128 bits  DHE-DSS-AES128-SHA
    Failed    TLSv1  128 bits  AES128-SHA
    Failed    TLSv1  168 bits  ADH-DES-CBC3-SHA
    Failed    TLSv1   56 bits  ADH-DES-CBC-SHA
    Failed    TLSv1   40 bits  EXP-ADH-DES-CBC-SHA
    Failed    TLSv1  128 bits  ADH-RC4-MD5
    Failed    TLSv1   40 bits  EXP-ADH-RC4-MD5
    Failed    TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
    Failed    TLSv1   56 bits  EDH-RSA-DES-CBC-SHA
    Failed    TLSv1   40 bits  EXP-EDH-RSA-DES-CBC-SHA
    Failed    TLSv1  168 bits  EDH-DSS-DES-CBC3-SHA
    Failed    TLSv1   56 bits  EDH-DSS-DES-CBC-SHA
    Failed    TLSv1   40 bits  EXP-EDH-DSS-DES-CBC-SHA
    Failed    TLSv1  168 bits  DES-CBC3-SHA
    Failed    TLSv1   56 bits  DES-CBC-SHA
    Failed    TLSv1   40 bits  EXP-DES-CBC-SHA
    Failed    TLSv1  128 bits  IDEA-CBC-SHA
    Failed    TLSv1   40 bits  EXP-RC2-CBC-MD5
    Failed    TLSv1  128 bits  RC4-SHA
    Failed    TLSv1  128 bits  RC4-MD5
    Failed    TLSv1   40 bits  EXP-RC4-MD5
    Failed    TLSv1    0 bits  NULL-SHA
    Failed    TLSv1    0 bits  NULL-MD5

  Prefered Server Cipher(s):
    SSLv3  256 bits  AES256-SHA

From what I have read, the nettalk webserver defaults to SSLMethodSSLv23 which sets it to accept TLS1, SSLv2, and SSLv3. Maybe forcing it to SSLMethodSSL2 will fix the issue?

[Update]: Using Self.SSLMethod = NET:SSLMethodSSLv23, SSLMethodSSLv2, and SSLMethodTLSv1 all produce the same results from the SSLScan on the NTWS.

[Bruce]

What's interesting is that I tested here on a Windows XP Pro, Service pack 3 (version 2002) machine running IE 8.0.6001.18702.
Which sounds like the exact machine you're testing on.

Despite the Verisign page, I'm able to connect to www.clarionshop.com, (which is a NetTalk server set up in exactly the same way your server is set up. An SSLScan to www.clarionshop.com returns the same as your server does.

Which implies that not all IE8 on XP3 are in fact created equally. I can only surmise that some Windows-Update is installed on this machine that's not installed on yours. (It would be interesting to know if you can browse www.clarionshop.com from your machine).

>> From what I have read, the nettalk webserver defaults to SSLMethodSSLv23 which sets it to accept TLS1, SSLv2, and SSLv3.

It used to, but in the later versions of NT4, and for a while in NT5, it enforces SSLv3 only. From a security point of view accepting SSLv2 is a problem. Obviously in your case, less of a problem since your app is internal. I believe you are still on NT4 right? I will need to make a new NT4 build to allow you to force SSLv2 explicitly - or you need to use a version of NT4 prior to 4.55 (ie 4.54 or earlier). (If you want to go the 4.54 route let me know and I can dig out an install for you.)


>> Using Self.SSLMethod = NET:SSLMethodSSLv23, SSLMethodSSLv2, and SSLMethodTLSv1 all produce the same results from the SSLScan on the NTWS.

yes, as above that setting is ignored in 4.55 and later.

Cheers
Bruce

[Proxus]

Which implies that not all IE8 on XP3 are in fact created equally. I can only surmise that some Windows-Update is installed on this machine that's not installed on yours. (It would be interesting to know if you can browse www.clarionshop.com from your machine).

I am able to browse the site and here is the certificate info:

>> From what I have read, the nettalk webserver defaults to SSLMethodSSLv23 which sets it to accept TLS1, SSLv2, and SSLv3.

It used to, but in the later versions of NT4, and for a while in NT5, it enforces SSLv3 only. From a security point of view accepting SSLv2 is a problem. Obviously in your case, less of a problem since your app is internal. I believe you are still on NT4 right? I will need to make a new NT4 build to allow you to force SSLv2 explicitly - or you need to use a version of NT4 prior to 4.55 (ie 4.54 or earlier). (If you want to go the 4.54 route let me know and I can dig out an install for you.)


>> Using Self.SSLMethod = NET:SSLMethodSSLv23, SSLMethodSSLv2, and SSLMethodTLSv1 all produce the same results from the SSLScan on the NTWS.

yes, as above that setting is ignored in 4.55 and later.

Cheers
Bruce

We are using NT5 at the moment and I realized yesterday that the actual encryption level we need is the SSLv3 version of RC4-MD5 (128 bit) but that encryption level is still failing on the ssl scan. However it is being "Rejected" instead of a flat out fail so I was wondering if there was any way to get the NT5 WS to communicate using the SSLv3 version of RC4-128 since that is the highest level of encryption allowed on IE8?

Our "company" is currently in the process of planning a transition to Windows 7 which would bump the browser to IE9 which will support AES-256 like all the cool kids do. However, when it comes to OS deployments it could take a very long time to see a full transition and it would be much preferable to encrypt all of the data well before that date if possible.

[Bruce]

What seems strange to me is that the IE on your machine can access www.clarionshop.com, (and if you SSLSCAN that you'll see it only supports
 Supported Server Cipher(s):
   Accepted  SSLv3  256 bits  AES256-SHA
   Accepted  SSLv3  128 bits  AES128-SHA
   Accepted  SSLv3  168 bits  DES-CBC3-SHA
   Accepted  TLSv1  256 bits  AES256-SHA
   Accepted  TLSv1  128 bits  AES128-SHA
   Accepted  TLSv1  168 bits  DES-CBC3-SHA

 Preferred Server Cipher(s):
   SSLv3  256 bits  AES256-SHA
   TLSv1  256 bits  AES256-SHA

So, I suspect there's something else in the mix here - perhaps an IE setting for local servers - I don't know.
But no matter. For version 5.30 I've added a setting;

This goes in the WebServer procedure, right after the call
ThisWebServer.SSLCertificateOptions.PrivateKeyFile = .....

Code: [Select]

ThisWebServer.SSLCertificateOptions.CiphersAllowed = 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT'
the default for this option is
'ALL:!ADH:RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:!EXPORT'
but as you can see, what you want is the medium level cipher turned on.

The format of the string is described here;
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

I'm hoping to get the 5.30 build out tomorrow (Friday).

Cheers
Bruce

[Proxus]

This is excellent news.

I am really looking forward to the update so we can get this up and running

Thanks for all the help Bruce!

[Proxus]

I installed 5.30 this morning to take another stab at correcting our SSL issues. So far I think I have a version that works in IE8 but it's still refusing to use any RC4 ciphers which I would prefer. Here are some pictures of what I find odd:




Not really sure why I'm getting these results but that's what I get no matter what I set the cipher string to.
The TLSv1 items started showing up after a clean/rebuild but I can't explain that either because I did a full reboot and Clean / Rebuild after the update.

It feels like the cipher string is being overwritten elsewhere but so far I have not been able to identify where...

Anyhow, the Triple DES 168 will work for the time being so thanks again for the help with the update, hopefully we can resolve this other little issue in due time.