PUBLIC MARKS with tags ssl & http

Set-Cookie Secure, Set-Cookie HttpOnly, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection

The Pound program is a reverse proxy, load balancer and HTTPS front-end for Web server(s). Pound was developed to enable distributing the load among several Web-servers and to allow for a convenient SSL wrapper for those Web servers that do not offer it natively. Pound is distributed under the GPL - no warranty, it's free to use, copy and give away. WHAT POUND IS: 1. a reverse-proxy: it passes requests from client browsers to one or more back-end servers. 2. a load balancer: it will distribute the requests from the client browsers among several back-end servers, while keeping session information. 3. an SSL wrapper: Pound will decrypt HTTPS requests from client browsers and pass them as plain HTTP to the back-end servers. 4. an HTTP/HTTPS sanitizer: Pound will verify requests for correctness and accept only well-formed ones. 5. a fail over-server: should a back-end server fail, Pound will take note of the fact and stop passing requests to it until it recovers. 6. a request redirector: requests may be distributed among servers according to the requested URL. Pound is a very small program, easily audited for security problems. It can run as setuid/setgid and/or in a chroot jail. Pound does not access the hard-disk at all (except for reading the certificate file on start, if required) and should thus pose no security threat to any machine.

Serving secure pages on a website is made a lot easier by having both your secure and insecure pages served by the same files - all you need to do is change the scheme from http:// to https:// and you're done. But how do you manage which pages should redirect to the secure server? And how do you make sure you redirect users back when they're finished submitting sensitive information?

This recipe describes how to set up a simple HTTP server supporting SSL secure communications. It extends the SimpleHTTPServer standard module to support the SSL protocol. With this recipe, only the server is authenticated while the client remains unauthenticated (i.e. the server will not request a client certificate from the browser). So, the client (typically the browser) will be able to verify the server identity and secure its communications with the server.