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.
Related
We have a client whose code was written in Java 1.7. Java 1.7 by default refuses to connect via HTTPS to servers who return an SNI unrecognized_name warning. It's possible to turn off this behavior, but (of course) our client can't do that. Most other clients just ignore the warning.
We have a valid wildcard certificate for our domain, let's call it *.widgets.com. Anything in the domain widgets.com resolves to our HAProxy load balancer. We've installed that cert onto the load balancer, and we specify it in the front-end that listens on port 443. The cert is current and checks out fine when we test it from Qualys... except for that SNI warning.
Our client makes a call to a specific subdomain, say foo.widgets.com. The service is working fine, serving up content to anyone who calls it. Except for our client, of course, who won't connect to us after we return the SNI warning.
I've found lots of articles about how to solve this problem on Apache, but those don't help me with HAProxy. On HAProxy, I see that I can specify more than one cert, and I am told that HAProxy will "choose the right one". Do I need to get a separate, non-wildcard cert for foo.widgets.com? I don't want to buy another cert only to find out that that was not the solution.
Turns out the problem had little to do with HAProxy. Apparently we had an intrusion detection system in place that would terminate TLS prior to relaying down to HAProxy.
There is probably a way to make the IDS behave properly, presenting the correct certificate to the client. But we don't really need IDS on our non-prod environments, anyway. So we left it switched off, and the problem went away.
So if you're having a similar issue, after making sure that your certificate is good for the request you're testing, my advice would be to check whether you have any security software that could intercept traffic before it reaches your LB.
I am currently using lighty as a load-balancing reverse-proxy for two different webapps running on a small farm of HTTP servers:
roundrobbin(URL_1) => Server_Group_1
roundrobbin(URL_2) => Server_Group_2
I want to convert the HTTP servers to HTTPS servers. URL_1 has CERT_1 and URL_2 has CERT_2.
Unlike many people, I do not want to serve certificates from the front-end proxy. I want the front-end proxy to pass the HTTPS requests to secondary proxies: Proxy_1 (serves CERT_1) and Proxy_2 (serves CERT_2).
This should be possible with SNI (Server Name Indication). But everything I have read about SNI gives the example of front-end proxy serving both certs. I do not want to put both of my certs on the fron-end proxy. Call me crazy, but I actually want to hold the certs closer to the apps.
This might seem like a lot of trouble for two URLs. It is. My real case involves dozens of URLs. So it might might seem silly not to store all the certs in one place. But there are 'organizational considerations' which make it advantageous to administer them separately.
So basically, I want to use SNI for pure forwarding and defer SSL termination to downstream.
Thanks for reading. I expect to learn a lot from this!
What you're trying to do doesn't rely on an HTTP reverse proxy but on a reverse proxy at the TCP connection level, with the additional capability of being able to recognise an SSL/TLS Client Hello, look for the Server Name extension and dispatch accordingly.
I realise this isn't quite the answer you're looking for, but I wouldn't look at HTTP servers for this.
It looks like this project might be able to do this (I haven't tried).
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.
My client ask me to do reverse ssl on his website. But i'm new on this term. Can anyone help me about this.
Please describe or refer how to do it.
Check out this wiki article.
In the case of secure websites, the SSL encryption is sometimes not
performed by the web server itself, but is instead offloaded to a
reverse proxy that may be equipped with SSL acceleration hardware.
"Doing" reverse SSL means choosing a system/server and configuring it. You should start by asking your client whether they already have a reverse proxy in place or if one needs to be set up.
So setting up reverse SSL (like standard SSL) should not impact your web site's design, the backing code and data store etc. It is Transport Level Security (TLS) and might actually be outside the bounds of the contract with your client.
One use case would be running Apache Tomcat behind an Apache Web Server which handles SSL and acts as reverse proxy. Your client should specify more specifically.
I've got a local application (which I didn't write, and can't change) that talks to a remote web service. It uses HTTPS, and I'd like to see what's in the traffic.
Is there any way I can do this? I'd prefer a Windows system, but I'm happy to set up a proxy on Linux if this makes things easier.
What I'm considering:
Redirecting the web site by hacking my hosts file (or setting up alternate DNS).
Installing an HTTPS server on that site, with a self-signed (but trusted) certificate.
Apparently, WireShark can see what's in HTTPS if you feed it the private key. I've never tried this.
Somehow, proxy this traffic to the real server (i.e. it's a full-blown man-in-the-middle "attack").
Does this sound sensible? Can WireShark really see what's in HTTPS traffic? Can anyone point me at a suitable proxy (and configuration for same)?
Does Fiddler do what you want?
What is Fiddler?
Fiddler is a Web Debugging Proxy which
logs all HTTP(S) traffic between your
computer and the Internet. Fiddler
allows you to inspect all HTTP(S)
traffic, set breakpoints, and "fiddle"
with incoming or outgoing data.
Fiddler includes a powerful
event-based scripting subsystem, and
can be extended using any .NET
language.
Fiddler is freeware and can debug
traffic from virtually any
application, including Internet
Explorer, Mozilla Firefox, Opera, and
thousands more.
Wireshark can definitely display TLS/SSL encrypted streams as plaintext. However, you will definitely need the private key of the server to do so. The private key must be added to Wireshark as an SSL option under preferences. Note that this only works if you can follow the SSL stream from the start. It will not work if an SSL connection is reused.
For Internet Explorer this (SSL session reuse) can be avoided by clearing the SSL state using the Internet Options dialog. Other environments may require restarting a browser or even rebooting a system (to avoid SSL session reuse).
The other key constraint is that an RSA cipher must be used. Wireshark can not decode TLS/SSL stream that use DFH (Diffie-Hellman).
Assuming you can satisfy the constraints above, the "Follow SSL Stream" right-click command works rather well.
You need to setup a proxy for your local application and if it doesnt honour proxy settings, put a transparent proxy and route all https traffic into it before going outside. Something like this can be the "man" in the middle: http://crypto.stanford.edu/ssl-mitm
Also, here's brief instructions on how to archive this with wireshark: http://predev.wikidot.com/decrypt-ssl-traffic
You should also consider Charles. From the product description at the time of this answer:
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information).
For using https proxy to monitor, it depends on the type of handshake. If you local application does not check the server's certificate by CA's signature which you can not fake, and the server does not check your local application's certificate ( or if you have one to setup on https proxy) then you can set up a https proxy to monitor the https traffic. Otherwise, I think it is impossible to monitor traffic with https proxy.
Another way you can try is to add instrumentation probe at the routines of your client program where it send and receive messages from its https library. It needs some reverse engineering work, but should work for you for all situations.
I would recommend WireShark, it is the best tool to follow on different pieces of traffic. Although, I am not sure what can you see with SSL turned on. Maybe, if you supply it with a certificate?