Blog Stats

Meta

Archive for September, 2013

So today I received another complaint of Google Earth causing Internet Connectivity problems. In the past, I had ignored these because I was never able to recreate the issue as I did not have enough information on the method being used to cause it. This time I was a little bit more determined so I had one of the helpdesk techs show me first hand what was happening and armed with that I went off to install Google Earth on a lab and attempt to recreate. The steps to recreate are rather straight forward, just do a few searches and lots of zooming or scrolling in Google Earth until. At some point, the telltale sign that Internet connectivity had been lost would be indicated when when the Tour Guide pane became blank:

When operating normally, the Tour Guide pane displays images relevant to the place you are searching or viewing. At this point, any browser would also fail to connect to any external resource, e.g. the Internet, returning a page not found or other connectivity failure message. After what seemed like a couple minutes, connectivity would then be restored.

Some troubleshooting was already attempted earlier by pointing the browser to an unmanaged (free-for-all) proxy, which avoided the problem. My guess at that point was that our TMG was somehow cutting the connection for the workstation for some amount of time. Why? I also assumed that Google Earth is simple saturating the TMG with too many requests. Think about it, every search, zoom, scroll, and pan is basically a file-image request. Keep on doing that in a short period and you are likely to trigger some hardware or software appliance that a DoS attack is taking place. To backup my hypothesis, I turned to my latest and favorite tool, Network Monitor. I started a trace, reproduced the issue, and stopped the trace. The capture was fairly large so I needed to set a filter. Some quick searching through the standard filters revealed a filter for Http error (Load Filters > HTTP > http Error). After applying the filter, I could see the issue:

502 Bad gateway – Proxy Error (The number of HTTP requests per minute exceeded the configured limit). Some quick research pointed to this Forefront TMG article Overview of flood mitigation. In short, TMG rules may have to be modified or created to bypass flood mitigation for Google Earth. Currently, these are the two servers Google recommends for bypass:

maps.google.com

geoauth.google.com

This is also known to be an issue for home and small offices that are not behind a proxy. In those cases, it is likely the router’s firewall-DoS configuration that is the culprit.

A while back ago one of our internal servers presented an issue to us. While trying to navigate to it, we were running into the following warning: “There is a problem with this website’s security certificate…”

The real problem was that clicking the Continue to this website (not recommended) link didn’t let you proceed to the login page, it would simply refresh this page each time. To explorer causes with certificate issues in Windows you simply need to enable CAPI2 logging. CAPI is Microsoft’s cryptography API. Logging can be enabled by going into the Windows event viewer > selecting Application and Services Logs > Microsoft > Windows > CAPI2:

Right-click the Operational log and select Enable Log. Recreate the issue, right-click the log again, select Disable Log, and look at the individual events, especially those error events. You will need to scan through the Details tab to isolate the issue as no general information is provided. This is not as bad as it looks. You don’t necessarily need to understand everything you are looking at. The Internet and your favorite search engine can handle the rest. In this case, I started by copying the ErrorStatus lines that had a boolean of true into my search engine. I hit pay dirt when CERT_TRUST_HAS_WEAK_SIGNATURE pointed me to this Microsoft KB article Microsoft Security Advisory: Update for minimum certificate key length. In short, Microsoft disabled support for weak key lengths, i.e. lengths that were not equal to or more than 1024 bits. From the certificate error below, I could see that the key length for the certificate the server was using was only 512 bits long:

To work around the issue, we needed to enable support for weak certificates on those workstations that needed access to the site. To do this, open an elevated command prompts and type certutil -setreg chain\minRSAPubKeyBitLength 512. See the KB article for more command line options. This can also be toggled in the registry at HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config and creating a DWORD of minRSAPubKeyBitLength equal to 512.

Upon trying to connect to a vendors website application, a user was seeing an error pointing to a failed certificate validation:

With java logging enabled, the details were more specific:

com.citrix.sdk.jsse.CitrixSSLException: The certificate validation failed. at com.citrix.sdk.jsse.SocketFactory.createSslSocket(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.citrix.client.io.net.ip.proxy.o.a(Unknown Source) at com.citrix.client.io.net.ip.z.a(Unknown Source) at com.citrix.client.io.net.ip.z.a(Unknown Source) at com.citrix.client.module.td.tcp.TCPTransportDriver.s(Unknown Source) at com.citrix.client.module.td.TransportDriver.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source) at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)

Looking at the certificate, I could see it was using the relatively old MD2 algorithm. While the user did not experience this issue previously, its worth noting we had just moved to Java 7 from 6. Likely JRE 7 has disabled support for MD2 because it is considered unsecure. Some quick research revealed this was the case. With the site outside of our control, a need existed for the user to be able to access the application. Instead of downgrading to Java 6, enabling MD2 support in Java 7 is a simple matter of editing the java.security file in C:\Program Files (x86)\Java\jre7\lib\security to comment out jdk.certpath.disabledAlgorithms=MD2 or simply remove the MD2 part: