> We have a website in which we will have an SSL component for order
> processing. We just found out that we will have a hardware SSL
> accelerator card within the network architecture. From what we
> understand, the card will TX/RX to the webfarm via port 80 for all
> traffic. This is new for us and do not know if there is anything
> special needed in the application layer to accomidate an SSL card vs.
> handling the SSL directly on the server within and ASP.net code.
>
> Has anyone seen this before and is there anything special that needs
> to take place on the application layer to make this work.

"Joerg Jooss" wrote:

> Thus wrote Nathan,
>
> > We have a website in which we will have an SSL component for order
> > processing. We just found out that we will have a hardware SSL
> > accelerator card within the network architecture. From what we
> > understand, the card will TX/RX to the webfarm via port 80 for all
> > traffic. This is new for us and do not know if there is anything
> > special needed in the application layer to accomidate an SSL card vs.
> > handling the SSL directly on the server within and ASP.net code.
> >
> > Has anyone seen this before and is there anything special that needs
> > to take place on the application layer to make this work.
>
> Generelly speaking, yes. Whenever you switch from HTTPS to HTTP in front
> of your application server, you have to consider a couple of things.
>
> The most obvious is the fact that IIS and ASP.NET will never receive a HTTPS
> request when you have front end SSL accelerator. Thus, if your application
> code has to know whether the original request has been sent over a secure
> connection or not, you'll need some help from the accelerator. Some of these
> devices for example are able to add a custom header to the HTTP request.
> Just remember that even with those work arounds in place, the standard ASP.NET
> infrastructure isn't likely to know about or use them, so avoid APIs like
> HttpRequest.IsSecureConnection or any equivalent server variables like SERVER_PORT_SECURE.
>
> A less obvious issue are HTTP redirects sent from your application code.
> You should avoid fully qualified redirect URLs, as these will always use
> HTTP instead of HTTPS (see above -- ASP.NET has no idea that the original
> request was using a secure connection). By default, ASP.NET doesn't redirect
> with fully qualified URLs, unless you set it in your configuration's <httpRuntime
> /> element.
>
> Cheers,
> --
> Joerg Jooss
> news-reply@joergjooss.de
>
>