I'm changed my iPhone app from using HTTP to using HTTPS and it just worked.
I doubt that it is actually working though. How can I check, from my Tomcat server log files (or similar), that the request actually used HTTPS?
Log the return value of request.isSecure() from a Servlet or JSP and see.
BUT: be aware that Tomcat, if not configured properly, won't KNOW if it's serving securely or not. This is the case whether your SSL cert terminates at your load balancer (or web server sitting in front of Tomcat), or if Tomcat is handling SSL traffic directly. Your (in server.xml) for HTTPS requests must have the secure="true" attribute; the default is "false". If secure is set to false (or not set), then Tomcat may be successfully handling SSL connections, but when you call isSecure() from within a Servlet (or JSP), it'll return false.
I don't know if the secure attribute affects how Tomcat logs traffic or not, but it may.
Related
My situation:
A website is hosted using a default apache2 installation on an ubuntu server.
Served on port 443 using HTTPS and a self-signed certificate (for developping).
Now I have a simple service written in golang that listens at port 8080 and acts as a Reverse Proxy to take https requests, forward them to apache locally and return the response back to the client. This webservice doesn't cache any files and only forwards requests.
Code: https://play.golang.org/p/tnfKVWyLuZQ
My "problem":
Calling apache directly, i.e. https://foo.com/bar/ is remarkably slower (200-400ms) than calling the website through my reverse proxy, i.e. https://foo.com:8080/bar/
Why is it slower to call apache2 directly? I expected to have overhead using a reverse proxy, not a speedup. -> Comparison for example page: https://i.imgur.com/TqznM2v.png
UPDATE: Sketch to show the current setup:
Current Setup
Regarding the encoding: The Encoding is consistent in both situations: Encoding header and Content-Length is in both cases (Situation 1 vs 2) the same, the client also receives the file size. Not sure why in the HAR Viewer it only displays the uncompressed size in the second case. If checking in Chrome I can see the compressed size in both case.
Update #2: I came to the conclusion that the golang implementation handles multiple requests from the same client in a short time more efficiently than apache2 in it's default configuration. Sicne I only test with few clients I can't say how well it scales - I imagine the webservice will fall behind when under load.
I see this as closed, thanks all for the help.
As far as i can see. There are two possible reasons.
The apache reverse proxy handled some cache contain static file like images, css or javascript.
When you browse a https url. A process named "ssl certificate uninstall" will happen, and it can cause huge server load. So if the web application and the ssl certificate are deployed on the same server, the load may cause high-latency. Generally, we use a special device named load-balancer to uninstall ssl certificate, Just like a reverse proxy.
I have two projects running on Wildfly-8 and I have two SSL certificates for each of them and one IP.
I figured out that I should have one IP for one SSL certificate.
But I needed to use these two SSL for one IP. I couldn't find a way to do it with Wildfly but there was a way to do it with Apache Server. So,I installed Apache Server up to Wildfly.
I listen https port(443) on Apache and redirect it to Wildfly's http port(I used 8080). It works without any problem.
What I wonder is;
1. Is Apache decrypt request and redirect it to Wildfly?
2. Is it correct way to do it or I have done it by chance?
3. Does this method create a security hole?
I googled some, but I could not find satisfied answers.
Thanks for replies.
For this answer, I'm supposing that by "redirecting" you mean "proxying": Apache receives the request, proxies it to Wildfly, receives an answer from Wildfly, sends the answer to the client.
If you mean something else, then the simple answer is: it is wrong[1].
Is Apache decrypt request and redirect it to Wildfly?
Yes. Apache will receive and send secure data to/from the client. Its communication with Wildfly will be plaintext.
Is it correct way to do it or I have done it by chance?
That's how it's usually done, yes. In other words: a load balancer and/or a proxy in front of Wildfly (Apache in your case). Wildfly itself is not reached directly by the public internet.
Does this method create a security hole?
It does, just like everything else is a security "compromise". In this case, you are trusting your internal network, in the name of a more practical/manageable architecture. If you do not trust your internal network, you should look for another solution. In the general case, the price to pay seems fair to me, as you'll "only" be open to a man-in-the-middle between your Apache and your Wildfly. So, if you trust your internal network, you should trust that there won't be any MITM there.
Edit
[1] - As everything else in life, there's no absolute truth. Basically, there are 3 techniques that can be used in a scenario like this: pass through, edge and re-encryption.
Pass through is a "dumb" pipe, where nothing about TLS is known by the proxy. Wildfly would then handle the secure communication with the client. I'm not sure Apache would do this, but this can be done with haproxy in TCP mode;
Edge (or offloading) is the situation I described above: Client talks TLS with Apache, Apache talks plaintext with Wildfly;
Re-encryption, which is like Edge, but the communication between Apache and Wildfly is also TLS, using a different certificate.
Hello I have seen a strange behaviour in Apache HTTPD SSL and TomEE (in fact it is a Tomcat so it is exactly the same for Tomcat), I am configuring the typical Apache as frontend and TomEE as backend solution. Currently Apache is configured with SSL and with mod_jk it connects to TomEE using AJP. This works perfectly. The problem is that inside my code I need to get the ssl session id:
String ssl = (String)servletRequest.getAttribute("javax.servlet.request.ssl_session_id");
I don't know why but sometimes this attribute is null and sometimes not. It may return a null at first then stay like 10 requests working and then stop working again during some requests and the get attribute returns null.
It seems that everything is configured correctly since sometimes works. Have you ever found something similar or knows what it can be happening? Do you think that maybe the problem is on client (browser) side?
Everything is dockerized here: https://github.com/lordofthejars/apache-tomee-ssl so you can review configuration files of tomcat and apache or even run it.
Thank you so much for your support.
when https is used on openshift, is my tomcat behind an apache server?
I mean does my clients connect to my tomcat directly or they connect to the apache server, and then the apache server connect to my tomcat through AJP connector?
If apache is the man in the middle, then I will not get my clients' IP address directly, but with x-forward http header. And I lose the control over certificate verification and trust management. At present, I am using mochahost's server. https does not get to my tomcat, but intercepted by an apache. I hate this.
Previously, I used another hosting service, even 2 apache servers are at front of my tomcat server. Even more ridiculous that 2 apache servers and my tomcat servers are on the same machine. This kind of configuration can only show the system architecture does not have the right ability to manage the whole thing.
By the way, I am talking about the Bronze/Silver plan. I guess Openshift is not different though I have not tried it yet. Anyone has a clear answer to my question?
https is against the man in the middle, but with tomcat server, in this world, there is no service that you can avoid the man in the middle. It is not because technology does not allow, but the people in charge does not really understand the thing, so not able and not willing to provide the right service.
I want to ask: if you use tomcat server, is there any hosting service provider who does not act as a man in the middle? No. There is none on this world at present (May 2014)!
jack
There is an apache reverse proxy located in front of your tomcat instance that does ssl termination. The Apache instance is at the node level, then tomcat runs on your gear.
We have an Apache servers, edge servers, running as a reverse proxy (in this scenario).
When a user connects to these servers they're required to use SSL X509 certs.
At one point a request has to be made to an ESB running BizTalk 2010.
When the Apache servers pass the request onto BizTalk, Apache is putting the SSL in the header of the message rather than "re-attaching" the SSL certificate, or re-sending the SSL certificate when the request goes out to the ESB. BizTalk is unable to, or I'm not sure how to configure it, read these SSL's that come with the request.
Is there a way of configuring Apache to send SSL's with a message that BizTalk can understand, when Apache is running as a reverse proxy? Or is there a way to configure BizTalk to read these SSL certs that come in the header?
Update:
Is Apache decrypting the entire SSL stack, and that's why it's having a hard time passing the SSL through normally? Is there any way to resolve this?
Someone recommended that we put all the client certs on Apache, and have Apache just load up one of those to and pass that on with the request to BizTalk. Any other ways around this?
You can use S/MIME components with BizTalk to pull off a certificate from a message. It sounds similar to what Apache is doing. Depending on what pipeline component you used, you would specify the certificate details as a property on the component. It is hard to tell you exactly which component (built-in or 3rd party) to use without more information on the the way Apache is doing this.
Is the SSL approach called SSL offloading? I recommend not putting the certs on the Apache server if you can avoid it because it will be more difficult to manage (from an ESB perspective). You would also lose some security between the Apache server and the BizTalk server.