Oct 032011
 

China constantly amuse me. Today, I was paged by some users that the website is unreachable. Okay, I am thinking, I’m using SSL on my website (free cert from StartCom) , that should avoid being GFWed in the first place, so it is a server problem, but servers are all fine.

Then, sniffing on my user’s machine, it seems the machien is getting fake RST (a typical effect being GFW blocked).  I then tried some other domains with certs from StartCom, they are blocked too! Damn, lucky me got a godaddy cert as a backup on the domain, so I load it up on the server, everything is now working again! It’s like black magic!!!

ok, so some rationale here, I think it is very possible that GFW is detecting StartCom certificate by sniffing the session parameters, as Iran demonstrated in blocking Tor. It then send fake RST to both server and client to interrupt the connection.

https://blog.torproject.org/blog/iran-blocks-tor-tor-releases-same-day-fix

 

Okay, what to do now? We need to figure out *which* part of the certificate they are using as keyword, unless they are blocking the whole CA (which I fear,but might be truth), Hopefully StartCom can do something to change the keyword in the cert too.

Oct 012011
 

I have a web application running of https://mydomain.com , which then issue ajax calls. Recently, some of my useres, complains that AJAX calls timeout/fail from time to time, despite the main UI loads fine.

I looked at the server log, and ask user to try again, then I found those calls never reach server!

Luckily I am able to remote re-produce the problem on user’s machine, I opened chrome’s developer console, and found this:

XXX mydomain.com/api GET (cancel) text/plain 30B 0B 0ms 0ms 0ms

Why are my calls canceled? In this case, my callback get a status_code = 0. Okay, then I think I should trace this call.

I open a new tab with chrome://net-internals, navigate to Events Tab. Filter it by “mydomain.com”, There’s a few red entries, indicating problems.

One of the entry shows

ssl/mydomain.com:443

Start Time: Sun Oct 02 2011 00:46:24 GMT-0700 (Pacific Daylight Time)

t=1317541584591 [st= 0] +SOCKET_POOL_CONNECT_JOB             [dt=10]
t=1317541584591 [st= 0]    +SOCKET_POOL_CONNECT_JOB_CONNECT  [dt=10]
                            --> group_name = "ssl/mydomain.com:443"
t=1317541584591 [st= 0]        HOST_RESOLVER_IMPL            [dt= 1]
t=1317541794095 [st=  0]       +SOCKET_POOL                   [dt= 22]
t=1317541794117 [st= 22]           SOCKET_POOL_BOUND_TO_CONNECT_JOB  
                                   --> source_dependency = {"id":1485081,"type":4}
t=1317541794117 [st= 22]           SOCKET_POOL_BOUND_TO_SOCKET  
                                   --> source_dependency = {"id":1485083,"type":5}
t=1317541794117 [st= 22]       -SOCKET_POOL                   
t=1317541794216 [st=121]        CONNECT_JOB_SET_SOCKET        
                                --> source_dependency = {"id":1485083,"type":5}
t=1317541794216 [st=121]    -SOCKET_POOL_CONNECT_JOB_CONNECT  
                             --> net_error = -200 (CERT_UNABLE_TO_CHECK_REVOCATION)
t=1317541794216 [st=121] -SOCKET_POOL_CONNECT_JOB

Wait, what? Then I open my website directly in the tab, click on the padlock icon, open up the certifacte and found the CRL service from godaddy. Then I tried to fetch that in the chrome, no wonder! It stalls!

Okay, now it is clear, Chrome won’t fire my request because it is not able to check the CRL on my certificate, it is probably for security reason, but that is a very hard dependency on godaddy CRL service being up, what can I do about that?!

If you meet the same problem, please star/comment on http://code.google.com/p/chromium/issues/detail?id=98794