INSSL Appliance

[BeckyHester]

This topic is dedicated to questions and comments related to the INSSL - HTTP Gateway with SSL support appliance.
The INSSL data sheet can be found at:
AppLogic 2.4.x: http://doc.3tera.net/AppLogic24/CatGatewayINSSL.html
AppLogic 2.7.x: http://doc.3tera.net/AppLogic27/CatGatewayINSSL.html (page will be published concurrently with 2.7 release)

Please post any questions and/or comments here.

[jemil]

the link to the data sheet for this appliance is not working. please corect this in the catalog main documentation too.

Thanks,
Emil

[PeterNic]

Emil,

Thank you -- these should now work both ways (from doc to forum and back); I appreciate the feedback.

Regards,
-- Peter

[kapow]

I thought I would post this for those of you who might be using Ruby on Rails and Mongrel with SSL and need the INSSL appliance for your application.

Rails needs a special HTTP header to that it understand whether to redirect to an SSL connection or not. That header is X-Forwarded-Proto.

The INSSL appliance uses pound (http://www.apsis.ch/pound/) as load balancing proxy server. To configure it to pass along the X-Forwarded-Proto header, you must first branch the INSSL class. Once branched and your appliance is save, start it up.

Login to your branched INSSL appliance and change directories to /etc/pound. Edit the file pound_https.conf. Add the following two lines before the End statement:


HeadRemove "X-Forwarded-Proto"
AddHeader "X-Forwarded-Proto: https"

Your entire pound_https.conf should look like this:


ListenHTTPS
Address XXX
Port 443
Client 20
Cert "/mnt/key/server.pem"
HeadRemove "X-SSL-Request"
AddHeader "X-SSL-Request: 1"
HeadRemove "X-Forwarded-Proto"
AddHeader "X-Forwarded-Proto: https"
End

Note: This will not take affect until your app instance is restarted.

Test your Rails app to ensure that it reforwards https requests appropriately.

[PeterNic]

Kapow,

Thank you very much for posting this solution here. We should be able to include an option for adding the needed header in the next release of INSSL.

Regards,
-- Peter

[kapow]

I'd like to configure the INSSL appliance to redirect any http requests to https. Any clues on where do do that? Thanks

[PeterNic]

Kapow,

The current version of the INSSL appliance does not provide this feature. It is a good idea, though -- thanks, we'll try to include it in one of the next releases.

In terms of what can be done now: the simplest approach would be to provide redirection in the web server, based on the presence of the "X-SSL-Request: 1" header (or, rather, on its absence).

I will also discuss this with the maintainers of the INSSL appliance, to see if there is an easy way to do this in the INSSL appliance (e.g., by branching INSSL and making a small change there).

Best regards,
- Peter

[LeoKalev]

There may be a limited ability to make Pound redirect HTTP requests. This can only be done to a few fixed URLs (e.g., any HTTP URL goes to the home page), there is no way to tell it to redirect to the same exact HTTPS resource as the incoming HTTP request.

To do this, a Service section with a Redirect directive (or several of them, if desired) needs to be added inside the ListenHTTP ... End section in the config file. Example:
ListenHTTP
Service
URL "*"
Redirect "https://...."
End
...
End
This is not exactly trivial to add to INSSL because the redirect target URL must be made to match the hostname of INSSL itself, so unless one wants a single instance of INSSL for a particular web site with a hard-coded URL, this portion of the configuration file will have to be generated at boot time.

[PeterNic]

So one approach would be to:

Branch INSSL
Add a property hostname
Edit the config file to add the section above, use markup to put in the hostname property
Test and move back to a catalog (e.g., user)


Another approach (dumb but will do the job and is simpler -- does not require branching INSSL):

Configure INSSL for https only. This will route all http traffic via aux
Connect a small WEB server to INSSL aux (directly, or via PS8 if you use aux for other traffic)
Put a script in the WEB server that takes the given URL and redirects to http.


(For the future, we can add this to INSSL; the redirection can be done by thttpd or a perl script inside INSSL; it is not necessary for pound to listen to http in this mode)

Regards,
-- Peter

[PeterNic]

A quick diagram of an app with the http redirect using a separate small web server. The redirect script can be placed on the appliance's content volume (read-only).

[kapow]

Thanks. Another question:

I have purchased a certificate from a provider, but that provider's instructions are that I must install an "intermediate" certificate as well. They have instructions for Apache, etc., but how is this done for the INSSL appliance?

[PeterNic]

Kapow,

If they are delivering a bundled certificate, you can probably use the normal certificate installation procedure for INSSL. If that doesn't work, I'll escalate this to someone who can work with you to get the installation done.

For reference on intermediate certificates:
https://certs.starfieldtech.com/InstallationInstructions.go
http://www.whichssl.com/intermediate_certificates2.html
http://www.whichssl.com/intermediate_certificates.html

Regards,
-- Peter

[kapow]

There are two certificates, the authorized one which I used to create server.pem and this intermediate one that I must install somewhere. There are installation procedures for tomcat, IIS, apache. Here's the one for apache if it helps:

Installing SSL Certificate and the Intermediate Certificate

Copy your SSL certificate file and the intermediate bundle file to your Apache server. You should already have a key file on the server from when you generated your certificate request.
Edit your Apache configuration to reference these files. The exact configuration file you will edit will depend on your version of Apache, your OS platform, and/or the method used to install Apache. In Apache 1.3, you will most likely edit the main httpd.conf file. In Apache 2.x, you will most likely edit the ssl.conf file.
Locate the following directives. If one or more of them are currently commented out, uncomment them by removing the '#' character from the beginning of the line. Set the values of these directives to the absolute path and filename of the appropriate file:
SSLCertificateFile /path/to/your/certificate/file
SSLCertificateKeyFile /path/to/your/key/file
SSLCertificateChainFile /path/to/intermediate/bundle/file
Save your configuration file and restart Apache.

[kapow]

UPDATE!

I have gotten this work after finding an obscure sentence in the last line of a blog post. Since INSSL uses pound and pound serves up the cert, you must create your server.pem to contain all three certs in a certain order. That order is:
- privkey.pem
- your signed cert
- the issuers intermediate cert. In the case of GoDaddy that is sf_issuing.crt

So the cat command is:

cat privkey.pem yourissued.crt sf_issuing.crt > server.pem


Now, by default this works fine in Internet Explorer. However, FireFox knows nothing of GoDaddy as a certificate authority. You must import godaddy as a certificate authority from one of the certificates and then it works fine.

I recommend updating the docs on INSSL to add some information on intermediate certificates as it appears that Verisign requires them now as well.

[Pavel]

Kapow,

You should be fine by putting just the private key and the certificate in a single file (in that order). This is described in INSSL documentation:


Using existing apache+mod_ssl certificate

* If you have a certificate that you use in Apache, you can use it in INSSL as well, just make sure the key is not password protected (see above) and put the certificate and the key in one file.

[PeterNic]

Kapow,

Thanks for your notes -- we will update the INSSL documentation to include the procedure for preparing the certificate file when intermediate certificates are present.

Regards,
-- Peter

[PeterNic]

Hi,

For those who use the INSSL and the header fields it embeds in the request it forwards, here is a small but important change:

In AppLogic 2.1.x, INSSL sets the "X-SSL-Request: 1" header if the request came over https
In AppLogic 2.3/2.4+, INSSL sets the "X-Forwarded-Proto: https" header instead


For some pound-specific reason, it was not possible or wise to keep the old header as well. As a result, if in a web server connected to INSSL, you had URL rewrite configuration statements that tried to forward anything coming over http to https; or tried to distinguish between http and https, you will need to change the configuration file.

For example, in AppLogic 2.1.x, the URL rewrite statements that forward all http to https would be:

# redirect http to https
RewriteCond %{HTTP:X-SSL-Request} !=1
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]


In AppLogic 2.3+, the URL rewrite statement would become:

# redirect http to https
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]


Also, if you use local wget (e.g., to invoke URL on a cron job), you may want to add an exclusion for localhost gets, the result looking like this:

# redirect http to https (exclude localhost wget, e.g., for a cron task)
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteCond %{REMOTE_HOST} !=127.0.0.1
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]


(These statements would go in the .htconf file of a WEB5-type appliance that is connected to INSSL's output, either directly, or through a load balancer or similar plumbing. For more details on WEB, see its datasheet/documentation).

Regards,
-- Peter

[danielc]

Hi,
We are using a hacker scan solution and they recently discovered that our SSL version is 2 instead of 3 (or it permits v2 connection). When i try to view the details of the SSL certificate in browser it is displayed as 3.
Anyway their solution is to set something like this in the apache configuration file

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

The problem is that we are using and INSSL and the apache servers are behind load balancer. What is the solution in this case? Do i have to add something similar in pound.conf or just add this in my httpd.conf files and it should be fine?

Thank you,
Daniel

[Karl]

Being able to tweak the SSL/TLS protocols accepted and the ciphers accepted would be a nice feature to add to the INSSL and INSSLR - Our ASV picked up on it as well when we were testing an app out as well.

Any thoughts on replacing pound with HAproxy in the gateways?

[danielc]

Thank you for the fast response.
Currently i cannot do that because we are using HLB(http://doc.3tera.com/AppLogic2/CatSwitchesHlb.html) and making a new load ballencer is not a solution at this time
I'll try to see if i can find a workaround,
Thank you,
Daniel

[Karl]

Hi,

I was actually aiming that last question about HAproxy @ 3tera :)

As for HLB - There's a new version of that in 2.4.5 which uses HAproxy instead of Pound, hence why I asked about the gateways possibly switching as well :)

Thanks,

[danielc]

Hi,
The problem seemed to be from their end. Sorry for the trouble.
Thank you,
Daniel

[PeterNic]

@Karl,

Yes, we plan to rev INSSL to exorcise pound from it. Unfortunately, HAProxy will probably not work well, since it doesn't process multiple http requests in the same connection correctly -- for HALB this is OK, as we don't modify the header; it won't work for INSSL, as we need to add 1 or 2 header fields to EACH request.

Currently considered are nginx and apache. Any ideas?

@danielc - is the problem resolved?

Regards,
-- Peter

[Karl]

Yep, realised that when I did some more digging. Nginx FTW, Apache is waaaaay too bloated to be using for a gateway, been using Nginx quite a bit lately for some customers static content (on my todo list to make an appliance for it).

[tengel]

Given a newly designed grid, I've added an INSSL device and added an appvolume to hold the server.pem. How exactly does one go about actually getting that server.pem onto the volume itself so the INSSL device will start?

Do you NFS mount the volume on another machine first? scp it up somehow? Mount the volume in the commandline shell and copy a file from somwhere? The 3tera docs completely lack any instruction in the INSSL webpage what you're supposed to do here... my appvolume for the SSL cert is a small one unique to that device, I just need to get the file physically uploaded onto that volume.

[Karl]

Hi,

Depends on the version of AppLogic. If it's 2.4.5 then you'd open the volume manager in your app, select the volume and click the manage button - which opens up a graphical file manager.

Thanks,

[tengel]

Depends on the version of AppLogic. If it's 2.4.5 then you'd open the volume manager in your app, select the volume and click the manage button - which opens up a graphical file manager.

Thanks Karl -- it looks like the grid is "2.1.1 hf2192 hf2081 hf2195" so I don't get that cool option. How might I go about it on this 2.1.1 release? I see in the shell there are mount and unmount options, but I believe they're not the same as what I think.

[PeterNic]

tengel,

On 2.1.1 (any pre-2.3.9), you can:
1. Stop the appliance
2. In the grid shell, mount the volume: "mount vol <app>:<vol>"
3. Use scp or sftp to access the volume -- point it to the controller, it will be under a directory /vol/<app>/<vol> (or similar -- see docs, topic "Accessing the grid (http://doc.3tera.com/AppLogic2/GridAccess.html#Volume_Access)")
4. Put the pem file in the root of the volume
5. In the grid shell, unmount the volume: "unmount vol <app>:<vol>"
6. Start the appliance

The INSSL data sheet doesn't specifically say how to put the files on the volume since this is not appliance-specific (although I agree a link would have been useful).


Let me know if this helps,

-- Peter

[tengel]

Let me know if this helps,

Thanks Peter, helped a lot and makes sense -- I can't get my grid to recognize my public SSH key though for the scp, I'll followup with a support ticket on that one. The volume mounting and so forth though is straightforward.

[tmart]

The docs state the following for this INSSLR appliance:

Request Rate

INSSLR routes no less than 700 http or 120 https transactions (request/response pairs) per second, when operating on a single 2GHz CPU.

I would like to scale-up based upon some extrapolations of your numbers above; however, I would like to know if by "a single 2GHz CPU" you are talking about a physical CPU or a virtual CPU. Specifically, are your numbers based upon "1" CPU worth of resource assignment within AppLogic; or 1 physical CPU that might have as many as 4 cores (4 virtual CPUs) and you adjusted the CPU resource for the component appropriately to use all cores?

Since each grid has a different number of virtual CPUs available to a given component based upon how many cores are available, if your numbers represent timings based on more than "1" unit of CPU, then please update the docs with the specific number of cores used to generate your numbers.

To ask this question another way: I cannot imagine that your numbers would be the based upon the default AppLogic assignment for this class of "0.05" CPU (ie. 0.05 units of a 2GHz core), so what were your resource assignments for CPU and RAM that you used to achieve your SSL transaction numbers?

Thanks.

[Jsmart]

This measurement means when allocated 1 CPU within AppLogic; when the test system has 2Ghz processors that may be multi-core.

I believe the test was also ran at 1GB RAM as allocated tru the AppLogic interface. i will verify that.

--Jessie

[dkblinux98]

I have an app built on the Lamp Cluster and I need to have srv2 act as a mail server. I have ps8 out terminal 2 connected to the in of srv2 and have set up ssh for port 2222, 25 and then set srv2 to listen on port 2222 for ssh and sendmail is running on the srv2. I have done something similar on ps8 out5 to allow both ssh and mysql to go through ps8 to the database server so I have been able to successfully allowed two ports through inssl to ps8 to a server. For some reason though, this same setup for port 25 (as opposed to port 3306) is not working. telnet to port 25 on localhost of srv2 works, but externally does not. Any clues?

[PeterNic]

dkblinux98,

Port 25 is not unusual in any way in this. The obvious question: is there any possibility that you are trying to reach it from an ISP that blocks incoming and outgoing connections to port 25? (e.g., have you tried from, say, srv1 to reach outgoing to the input on port 25; or from another application running on the grid).

If that's not the problem, please search for my recent posts discussing how to troubleshoot connections to appliances (I think it is in the LINUX appliance post related to a Java console (http://forum.3tera.com/showthread.php?t=112)); let me know if this helps.

Best Regards,

-- Peter

[PeterNic]

(and, of course, having restarting the app with "app restart" without skipbuild, for the new parameterization to take effect)

[dkblinux98]

Thanks Peter. I will check the link you listed.

I did perform the diagnostic procedure of attempting to telnet to srv2 port 25 from srv1 in the same application. On srv2 the telnet to port 25 works. Otherwise it does not....nor anywhere else. I'm certain there is no blocking in place anywhere I've tested either from a corporate firewall or ISP perspective. I also did perform a full app restart. I find it very odd since I was able so easily to make this exact change for the db server (with port 3306 instead of 25) within the same application. Very strange. I'm sure it is something simple that I'm just not seeing. When I figure it out I'll post the solution.

[dkblinux98]

As promised I'm posting the solution. The server itself was set up by default to listen only on the loopback interface. I edited the sendmail.mc file and remade the sendmail.cf, bounced sendmail and all is well. Thanks folks.

[dkblinux98]

Ok so now I have another issue which seems to be a sendmail setup quirk specific to 3tera.

I resolved the port 25 issue but now my srv2 is seen as an open relay and I'm being flooded with email. This is because I have allowed relay from the internal ip address associated with the PS8 connection which provides the external to internal path to srv2. I added the internal IP as an allowed relay because all mail was being rejected with "Relaying Denied" coming from that IP.

Adding that IP shouldin't create an open relay. This is an unusual configuration issue that seems to be specific to the way 3Tera handles INSSL -> PS* -> srv2 and I'm stumped. Any help would be appreciated.

[PeterNic]

dkblinux98,

Actually, dgoepp had the exact same question - take a look at the http://forum.3tera.com/showthread.php?t=99 post.

I think the best solution here is to use a separate IN gateway for the incoming, relay-able e-mail, and use IN's allow_hosts to constrain the IP address of the senders.

Let me know if one of the two above helps.

Regards,
-- Peter