Safari not responding when HTTPS connections are unavailable

Question

Level 1

17 points

Safari not responding when HTTPS connections are unavailable

I'm using a 13" MBP with 10.7.2 installed, which is setup to sync calendar, address and bookmarks with iCloud. Since last week I've constantly encounter a problem that my Safari 5.1.1 would keep crashing, and I had to delete the ~/Library/Safari/extensions folder to get it back to work.

This situation happened whenever I've switch to wireless connection. In my office we've setup a limited wireless environment that all HTTP/HTTPS connections will be redirected through a proxy. Since last week the proxy server was malfunctioned. All HTTP connections are proceeded normally, but all HTTPS connections will be suspended. I'm not sure but I suspect it's the main reason for the crashing problem.

The syndromes are:

1. When I left Safari open, unplug the ethernet, and turn-on WiFi, everythings goes on normally, until I open an HTTPS web page, for example, https://www.icloud.com. Of course that HTTPS URL will not load, since our proxy is broken; but the connection itself will NOT timeout. I've tried to leave it connecting for 10 minuntes, and it's still there.

2. The statement above may due to a glitch in our proxy server and I can understand that. But the problem is: after I tried to open an HTTPS connection, the Safari will refuse to open any other URLs, including normal HTTP connections. It will just keep "connecting". Meanwhile the FireFox and Chrome can load these HTTP pages normally.

3. If I quit Safari in this situation, Safari will not be able to re-launce: the icon will keep bumping on the dock. I have to force quit Safari and delete extensions folder, so that it can be launched again. But even after Safari re-launced, it still refused to load HTTP pages.

4. Neither reconnecting WiFi, relogin, or switching back to ethernet can fix the problem. I have to restart the whole system to get it back to normal.

It seemed to me that some Safari-related process will keep in the system after Safari is quited. And that process may keep the inactivated HTTPS connections alive in its TCP pool, and blocked all sequence connections, including the iCloud synchronization. And while I force-quit Safari, the extensions.plist file is damaged. That's the only plausible explanation to this situation.

I'm sure this situation is introduced after 10.7.2: it's not the first time our proxy server breakdown, but I've never have this problem before.

Posted on Oct 23, 2011 11:23 PM

Reply

Answer 1

Richard Liu2 Author

Level 1

17 points

Oct 27, 2011 2:17 AM in response to Richard Liu2

OK, I've figured out something that might be useful:

First, Safari 5.1.1 will just Crash-On-Launch when HTTPS connections are unavailable. And it's confirmed that this crash condition is related to extensions. If there is no extension installed, Safari can launch normally. This crash condition can be 100% reproduced, and it's something new in 5.1.1.

Second, the HTTPS over WiFi via Proxy is an old problem. And it's a system wide problem.

http://blog.rog42.net/2011/osx-lion-wifi-https/

Third, in 10.7.2 this problem seemed go worse: When the first HTTPS connection fails, all sequence HTTPS connections will be blocked. Reconfiguration network interface (i.e. reconnect to ethernet) will NOT recover the HTTPS connections. The only way to solve this is reboot.

Reply

Answer 2

Richard Liu2 Author

Level 1

17 points

Oct 27, 2011 3:55 AM in response to Richard Liu2

I've done some detailed test and now I can give a conclusion:

1. It's confirmed that sequence HTTPS connection will be blocked in Safari and Google Chrome after a failure HTTPS connection (due to proxy). And rebooting is the only way to recover connections.

2. My previous observation is wrong: this is NOT a system wide problem. FireFox is not affected. FireFox will return to normal and all sequence HTTPS connection can be proceeded without any problem when I reconnect to a valid network connection (i.e. ethernet), while the Safari and Google Chrome remained being blocked. And DropBox is NOT affected as well.

3. None of the solutions mentioned in other threads can solve this problem. Checking the "Auto proxy discovery" does not help. Delete ~/Library/Preferences/com.apple.security.revocation.plistfile does not help. Clean Keychain does not help either. I've created another account for testing.

4. It's apparently something related to some system built-in network services. Since the FireFox and DropBox both gets its' own Proxy implementation, while Safari and Google Chrome will take the system settings. It's also worth noting that the POP3-SSL connection in Mail.app is also blocked after a failure HTTPS connection.

Currently the ONLY valid solution is using FireFox instead.

Reply