I've configured an Apache server as a front for a Tomcat. On the httpd server, I've configured an https connection. This connection is mandatory, so all requests made using http are redirected to the https schema. My site is really slow using this environment. I suppose that there is a misconfiguration somewhere, but I don't know where. I've made a capture with Wireshark, and I see some encrypted alert. Following advice I've found on some forum, I've read about those alert messages. Some are supposed to be ok, but some are not. For example I've seen an alert with the code 46. Is it possible that with this kind of alert my site would be encrypted, but really slow?? asked 17 Dec '12, 11:13  benzen edited 20 Dec '12, 05:53  Jaap ♦ |
2 Answers:
Code 46 means "certificate_unknown", so it might be a problem with the certificate checking process. Well, then the browser should display an error message. Without further information about your setup (OS version, server software, client software, certificates) it's hard to make a good assumption about the possible problem. One possible reason: If there is a CRL distribution point in your certificate, your browser might try to fetch the CRL and if it can't it may slow down your connection. The same is true for OCSP. Regards answered 17 Dec '12, 11:46  Kurt Knochner ♦ Sorry i'm fairly new to this. Could you explain to me what is a crl or OCSP. Maybe that could help to understand better, my cert is a self (17 Dec '12, 11:53) benzen
that are both methods to check the validity of a certificate.
Some questions:
Can you post the output of the following command?
You need openssl for windows to run this command.
(17 Dec '12, 12:05) Kurt Knochner ♦ In the browser, i didn't get any error. The webapp i'm building in this environement is pretty slow. And sometimes some resources are timedout. The cert is a slef signed cert. Also, i know that my cert is out dated. But since the site is still running, i didn't changed it. Can it cause a delay?? (17 Dec ‘12, 16:23) benzen
as it’s a self signed cert, you must have accepted the cert some day.
at the first glance, there nothing special/wrong with this self signed cert.
I don’t think so. What about my other questions?
New
(18 Dec ‘12, 00:34) Kurt Knochner ♦ I tryed with chrome, firefox, safari and opera. As i’m using macos i can’t test with ie. On the apache server i’ve got some messages like this [Sun Dec 16 06:47:20 2012] [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#7f612c001340 [mem: 7f612c006c73] And i also noticed that for a same session there is multiple handshake. I assume it’s the sign of a problem somewhere but i don’t know where. The application is really faster on plain http. I put the dump here https://docs.google.com/open?id=0B2y0ax8r16GxNHVuUmQzekF3S3c The ip of the server is 132.208.137.9 I dont’t have a copy of windows so i can’t use fidler (18 Dec ‘12, 05:16) benzen Following advice founded here I wondered if the session cache was working http://ldp.linux.no/HOWTO/Apache-WebDAV-LDAP-HOWTO/ssl.html This page recommend to try this command The handshake work well but when it try to reconnect here is what i’ve got drop connection and then reconnect (18 Dec ‘12, 06:19) benzen
That’s not a good sign ;-) That message occurs with several apache bugs.
I suggest to use the debugging methods shown in the bug reports to figure out what’s going wrong. Please also search google for debugging hints for apache or ask in a apache forum. To me it looks like an apache configuration issue (or a bug).
What is you client OS? There are similar tools for Linux (http://portswigger.net/burp/). (18 Dec ‘12, 06:37) Kurt Knochner ♦
Can you please post the whole output of the following command (including the
(18 Dec ‘12, 09:20) Kurt Knochner ♦ any progress on the (19 Dec ‘12, 08:21) Kurt Knochner ♦ As you mentioned it could be a mis conf of the apache server Here is my site conf Any comment would be helpful (20 Dec ‘12, 05:17) benzen well, looks O.K. Can you please post the output of
(20 Dec ‘12, 06:35) Kurt Knochner ♦ wait a moment.
Please remove that line from the config and restart apache. Then repeat your tests. (20 Dec '12, 06:38) Kurt Knochner ♦ ??? see my comment above your 2nd post of the config..... (22 Dec '12, 09:14) Kurt Knochner ♦ I just test to remove the SSLCACertificateFile But i didnt't see any difference in the response time (22 Dec '12, 23:51) benzen When executing the openssl command, nothing is added to the given log file. (22 Dec '12, 23:58) benzen can you please post the (23 Dec '12, 02:15) Kurt Knochner ♦ Here is my output for the command openssl s_client -debug -connect your.server.dom:443 -state -reconnect (24 Dec ‘12, 05:34) benzen I don’t see any ssl/tls related errors in the debug output. There are some inconsistencies, however I believe that’s from your attempt to anonymize the output (removing site specific information). BTW: The mentioned error is also no longer there: So, you must have changed something in your environment, right? Maybe the restart of apache fixed that specific problem!?! Looking again at your capture file I don’t see any ssl/tls or network related problems for your reported performance issue. Actually, the tls connections are all quite fast (< 1 second), with exception to the last 5 streams.
then
As you can see, the duration of all conversations (except the last 5) are << 1 seconds, which should be O.K. The duration of the last 5 conversations is ~7 seconds. However, if you look at them in detail, you will see, that there is a delay of 5 seconds before the connection is closed. That delay comes most certainly from your Keepalive timeout of 5 seconds. So nothing special there as well. IF however you run into the timeout a lot, then you might get into trouble, as most browser will only open a certain number of parallel connections to one sever. So, if the client does not reuse the connection (for whatever reason), it will wait until the connection gets closed until it can open a new connection for the next request. If you sum up all those wait times and you have a lot of request, then you will experience severe performance problems. However, the posted capture file is to short for that kind of analysis. Conclusion: After you have changed the configuration (removed There might be an issue with the keepalive timeout (see above). However, I can’t explain why it would be faster with http. As you did not provide any data to show how much faster it actually is with http, I cannot judge on that. Recommendation: You need to either decrypt the SSL/TLS communication with Wireshark (you need the server key) and then look at the single requests and responses, or use tools like Fiddler2, burp, or Firefox HttpFox. Additionally I recommend to enable debugging in tomcat and check the logs together with the output of the mentioned tools. Additionally try to modify the Keepalive timeout value (reduce it to 1 second) and check if your application is faster. Regards (25 Dec ‘12, 15:23) Kurt Knochner ♦ showing 5 of 18 show 13 more comments |
I opened your pcap file and looked at the SSL sessions to server 132.208.137.9. I used the filter "ip.addr==132.208.137.9 && (tcp.flags&7 || ssl)" to get a "clean" view on the traffic. Here are my findings:
Since SSL is a big CPU burden on a system (that's why there are a lot of devices offloading SSL from the server), my suspicion is that your server just can't take the load once all traffic is encrypted. answered 19 Dec '12, 06:40  SYN-bit ♦♦ Thanks for the comments. The KeepAlive is enabled on the apache conf. But i don't know a way to test that it's working. When running a similar scenario as the on of the pcap file and looking at top (the unix command) result. I don't see any significant load caused by apache nor openssl. The only load comes from the tomcat server that sit behind the apache. (19 Dec '12, 06:46) benzen You can check by looking at the http data inside the ssl sessions. One way to do this is by adding the plugin httpfox to FireFox and then connect to your server. You should be seeing headers like: ... in the server response. To compare performance over HTTP and HTTPS, it is best to do the same steps over HTTP and HTTPS and capture the data (please start the trace before starting the browser, to capture the full SSL handshake). If it is possible for you to share the private key (or use a temporary certificate during the test), that would give more insight... (19 Dec '12, 08:12) SYN-bit ♦♦ |
as you posted the same config file twice, I believe you did not see the show all link in the series of my comments, right? Click on it and you will see all comments, including a suggestion of mine regarding the config file.