An SSL non-gateway thingie

[csgno1]

The goal I have in mind is using a single IP address for the public interface while supporting a number of applications that use SSL and have the SSL-converting benefits of the INSSL gateway.

I mean I need to run, on a single IP address, app1 on port 9000 and app2 on port 9001 and app3 on port 9002. I also need them all to use SSL, and I want to use the standard appliances like WEB5.

If I am not mistaken INSSL takes https on port 443 and makes it http on port 80 and everything else goes to aux untouched.

So what I think I wish for is an appliance with one 'in' terminal and one 'out' terminal. In the configuration I'd provide the cert volume, what the inbound port will be, and what the outbound port needs to be. The appliance would take the SSL traffic and out the other side is without it.

I'd use one IN gateway and a PS8, then use a few of these 'SSL non-gateway thingies'(tm) between the PS8 and my app servers.

Feel free to shatter my dreams, I have a thick skin. I bet some smarter person has a better way already.

[PeterNic]

csgno1,

#1
What you are proposing is very AppLogic thing to do -- add just the functionality you need in a separate appliance and assemble the rest. You will get a "pure SSL encoder/decoder", from port 443 to 80. It will work. You can use the stunnel package (http://www.stunnel.org/) for the ssl encrypt/decrypt. The benefits are (a) simple appliance, (b) very visual assembly and (c) amazing scalability, as you can run the SSL engine for each application on a separate server and get tremendous performance (if you need it). And (d) lack of interference in the performance of the SSL decoders between applications (i.e., just because one app is getting more traffic to encrypt/decrypt, others will not slow down).

The drawbacks: (a) you will lose the original client IP address and (b) it may require a bit too much resources if you don't need any notable performance. In my book the simplicity and visibility of the design always is worth a few extra resources unless you need to replicate the whole things many, many times (in which case, doing some optimization / integration pays off). If you had such an appliance (which I would unimaginatively call SSL), would you be OK with those two drawbacks?


#2
Another possible approach would be to branch the INSSL appliance (or the INSSLR from the latest AppLogic, which is based on nginx) and make it have multiple outputs, translating incoming traffic on the external interface from port:
- 9000 to port 80 on output out1
- 9001 to port 80 on output out2
- 9002 to port 80 on output out3
- etc.

(out1, out2 and out3 would be new output terminals replacing the http terminal; you can also name them app1, app2 and app3)

This way you can also connect a regular WEB5-type web server to each of out1, out2 and out3 (and, because this is done in the gateway, you will be able to pass the original client IP address).

We'll be happy to lend a hand in the nginx config file changes if you choose this approach (I am almost sure nginx can do it -- will ping the INSSLR appliance developer to verify).


#3
Another approach if you care only for running multiple apps side by side and not about the ports as a multiplexing mechanism. If you would use differing URLs (either host name or directory), you can also simply use INSSL (or INSSLR) and the new URLSW appliance. This way, you can, for example use a wildcard SSL cert and have app1.domain.com, app2.domain.com and app3.domain.com all go to the same IP, pass them through INSSLR and then through URLSW, where you dispatch to out1/out2/out3 based on the host name. (Instead of using the host name, you could also use directories, e.g., domain.com/app1, domain.com/app2 and domain.com/app3 -- or any other method that URLSW can dispatch by.)


Let me know if any of those works for you. If there is interest, with a few diagrams I can move this discussion to the Architect's Corner forum.

Best regards,
-- Peter

[csgno1]

Hi,

I like option #1 because it's modular, even if not the most efficient way, I think it could be useful for a lot of people.

Option #2 I like for preserving the source IP, but in the context of the application I'm currently building I don't think it's important. Also if you design it with three ports would daisy chaining somehow work to get four or are we branching again?

The URLSW appliance sounds interesting, but it's not in my catalog to play with. It won't work to solve my current problem because one of the apps needs to use port 8080, but it sounds like a very handy thing to have. I'll write to support to see if I can get it in my version of AppLogic.

Thank you.