NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: Proxus on June 21, 2011, 10:47:43 AM
-
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?
-
Nothing springs to mind.
Is the site online? Can I acces it from here?
-
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 :(
-
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.
-
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.
-
not sure if it helps, but perhaps read this;
http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=1023.0 (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
-
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.
-
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
-
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:
(http://i.imgur.com/8nHue.png)
>> 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.
-
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 = .....
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 (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
-
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!
-
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:
(http://i.imgur.com/5Pa9Y.png)
(http://i.imgur.com/8jy18.png)
(http://i.imgur.com/6HH5C.png)
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.