On 7/28/08, Bobby Jack <bobbykjack@xxxxxxxxxxx> wrote: > I'm maintaining a site whose http/https configuration is all muddled up, partly because of the (lack of) facilities available in the CMS used to deliver it. However, I'm considering an apache-based solution which might solve things, and I'd like some feedback. > > The main problems revolve around the two following requirements (which are global to any properly built site using https): > > 1. Links (whether resident on an http or https delivered page) should begin "http://..."; or "https://";, as appropriate - i.e. dependent on which 'set' the target page belongs to. As far as I can think, those two sets are completely distinct, so this should not be a significant problem to resolve. > > 2. Certain resources (e.g. images, css, etc.) need to be requested via "http://..."; OR "https://..."; dependant on how the requesting page has been delivered. > > So, assuming I can solve problem 1 within the confines of the CMS, I'm thinking problem 2 can be resolved using RewriteRule with an appropriate condition on HTTP_REFERER. My one slight concern is the performance hit, although I'm guessing this should be minuscule, especially in relation to the hit of using https in the first place. > > Any thoughts? > Many thanks, > - Bobby Controlling whether HTTP or HTTPS is used for links and images is the responsibility of the "referer" HTML page. You should have three categories of URLs: 1. External URLs: The protocol is defined by the content. 2. Internal URLs requiring a certain protocol: The protocol is defined by the CMS/database/content. Whatever creates the URLs should look up the correct protocol. 3. Internal URL using the current protocol: Use relative URLs. Browsers create the absolute URL from the current page's URL, including the protocol. The protocols are set when creating the "referer" page, not when the images are loaded or a link is clicked. HTTP pages can be redirected to HTTPS. This requires telling the browser to ask again using HTTPS. Internal redirects are pointless since the server-to-browser communication would still use HTTP. Some websites only secure the login page. This also seems silly -- why secure content with access control and then send the content as cleartext so anybody can intercept it? After a visitor establishes credentials, the session should remain encrypted. SSL communication should be established before any confidential information is exchanged. Any HTTP URL should be considered outside the session. The Web was established when the Internet was still a nice place. Browsers should automatically send any form information using SSL. The insecure HTTP protocol should not allow GET querystrings or POST requests. Ideally, the only information outside the encrypted load of every request would be the target IP Address and server name. Changing the Web will be very difficult. Major websites like Google do not encrypt most requests. SSL places the server name inside the encrypted load so only one SSL server name is allowed per IP Address making SSL almost useless for virtual servers. OTOH, the additional bandwidth needed to encrypt everything might overload the Internet (and would have been unacceptable when most people used dial-up.) TMI? HTH, solprovider --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|