Community
Participate
Working Groups
When attempting to perform an HTTP Recording of SSL traffic on Windows Vista, the recorder is unable to establish a connection to the server. No security warning is presented (like we normally get due to re-direction through our recorder proxy server). It is assummed that this is due to some new security feature in Windows Vista. At this time, there is no known work-around or code fix approach in hand to address this issue.
Created attachment 55927 [details] Ethereal trace file
Created attachment 55931 [details] Etheral trace file showing entire conversion. In this recording I used another vista machine (9.37.207.132), who had its IE set to use a socks proxy set to the machine running the recorder process (9.37.207.21). I used this method because in the normal local recording I was unable to trace loopback traffic using Ethereal and was unable to see IE to recorder process traffic. The results are the same, a IE browser on Vista is unable to record SSL traffic. Interesting enough, we were able to take a non-Vista IE, point it to the Vista recorder process, and record SSL traffic. This seems to point to some sort of security setting on Vista IE stopping this SSL conversion.
It has been found that SSL recording works on Vista using FireFox. No SSL recording solution found for Internet Explorer at this time. At least this narrows it down to the version of IE 7 that is installed on Vista or some not so obvious settings somewhere that are applied on Vista (as opposed to some blockage by the operating system).
(In reply to comment #3) Does IE7 work on XP?
Yes, IE 7 SSL recording works on Windows XP SP2. As far as targeting, I believe we should target the fix for 4.2.2 and hope that we find a solution.
[Duwayne Morris] There is no known fix at this time.
DuWayne has done all the research on this and has ideas on how to fix this. I suggest reassigning this to DuWayne. Reassign to me if you feel necessary.
Found this link on Microsoft.com describing the behavior we see when there is a problem with the server Security Certificate. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/cols/dnexpie/ie7_https_imps.asp Importing the Hyades certificate into IE as a trusted certificate and importing it as a Trusted Certificate Authority was no help. It is now expected based on this info that the same thing will happen to IE7 on Windows XP. This appears to be strictly an IE security measure that happened first on Windows Vista.
Adding some further behavior notes. Connecting from IE 7 on Vista to a proxy recorder running on an XP machine gives the same error message on SSL, will not connect, while non-SSL works fine. This is an added demonstration that perhaps IE 7 on Vista recognizes the proxy address attempting to establish an SSL connection and blocks because this is a man in the middle attack. Connecting to a server without a trusted certificate provides a different error message. It also provides an option to view/import the certificate and to proceed with the connection. So, the problem we have is definitely associated with the specific behavior of a proxy server. I tested this by connecting to a Java SSL server running at my house via an IP address and that uses a certificate I generated for myself with no trusted CA. Perhaps we can overcome this by adding another layer of indirection with a normally acting proxy communicating through a hidden proxy. This may need to do some IP spoofing to work, just a thought. I don't think the solution is simple unless we can get some help from Microsoft.
Another experiment: Tested SSL to my untrusted site through a regular proxy server from IE 7 on Vista, no problem observed. Added Mark to CC list.
After discussing this defect at length with Dave Scott, it appears there are some actions that can be taken to further investigate. Dave has a more detailed understanding of the Ethereal trace info during the SSL hand shaking process and offered some suggestions to help either solve or at least clarify the nature of the issue further. Stay tuned for further info as it becomes available.
Good news! Details need work to determine the exact problem and find the best solution. It appears that there is a problem with the default choice of cipher suite. Using Advanced Options in IE, disabling TLS 1.0 to force the use of SLL v3.0 allows recording. re-start IE when switching this option. This is a work-around for the moment and I will work on a better solution.
Performing testing on a fix to request checkin. We currently have conditional code as follows in SSLCheckClass.java: if ((vendor.indexOf("Sun")) >= 0){ // The following to use Sun JVM ctx = SSLContext.getInstance("TLS"); kmf = KeyManagerFactory.getInstance("SunX509"); } else{ // or use the following for the IBM JVM ctx = SSLContext.getInstance("SSL"); kmf = KeyManagerFactory.getInstance("IbmX509"); } This was due to fact that at the time the code was written, the same connection string would not work on both Sun and IBM for the SSLContext (in addition to the KeyManagerFactory difference). Changing "SSL" to "TLS" or to "SSL_TLS" is working on the IBM 1.5 JVM without changing the default settings on IE 7 on Vista. I will put together a request to fix.
Created attachment 56831 [details] Fix for SSL Recording via Internet Explorer on Vista Changes are in SSLCheckClass.java
Attached a patch for the change made in SSLCheckClass.java. The initialization of the SSLContext for the IBM JVM was changed to use "SSL_TLS" instead of "SSL" in setting up the proxy SSL Server. The problem was that through whatever fault or changes exist in Internet Explorer 7 on Vista (or a fault in the JVM), there was a failure to agree on an acceptable cipher suite on Vista, thus the connection was closing at the end of the hand shake. The expansion to include both SSL and TLS in the SSLContext resolved the issue.
Checked in the fix for this defect on Friday, Jan 12 after testing on supported JVM's and on Linux and Windows. Plan to file new defects to merge this change into other branches.
Please use this defect to check-in the fix for 4.3.1 and 4.4 (HEAD).
Approval request: http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg02850.html
Closing this defect again. A decision was made to create separate defects for merging the fix to this defect into the 4.3.1 and 4.4.0 branches.
Reporter: Please verify and close in preparation for shutting down the TPTP 4.4 release. Thanks.
Verified.
Closing.
