Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)                      9  TCP/IP Hypertext Transfer Protocol (HTTP)                           9  HTTP Features, Capabilities and Issues

HTTP Proxy Servers and Proxying 1 2 HTTP State Management Using "Cookies"

Security and Privacy Concerns and Issues

Both RFC 2616 and 2617 also address some of the specific security concerns and threats that can potentially affect HTTP clients and servers. These include actions such as spoofing, counterfeit servers, replay attacks and much more. One concern addressed is the potential for “man-in-the-middle” attacks, where an attacker interposes between the client and server. Since proxies are inherently “men in the middle”, they represent a security concern in this area. The same authentication methods used for servers can also be applied to authentication with proxies. The Proxy-Authenticate and Proxy-Authorization headers are used instead of WWW-Authenticate and Authorization.

The standards also discuss a number of privacy issues. Some that are worthy of note:

• Handling of Sensitive Information: The HTTP protocol can carry any type of information, and it does not inherently protect the privacy of data in HTTP message entities. To ensure the privacy of sensitive information, other techniques must be used (which we will discuss shortly).
  
  
• Privacy of Information in URLs: One issue that sometimes arises in HTTP is that poorly-designed Web sites may inadvertently encode private information into URLs. These URLs may be recorded in Web logs, where they could fall into the hands of people who could abuse them. An example of this would be a Web site that submits a user login and password to a server by encoding them as parameters of a GET request such as this:

GET http://www.somesite.com/login?name=xxx&password=yyy”

The POST method should be used instead for this sort of functionality, because it transmits its data in the body of the message instead of putting it into the URL.

• Private Information in Accept Headers: While this may seem strange at first, it is possible that private information about the user could be transmitted through the use of certain “Accept-” headers used for content negotiation. For example, some users might not want others to know what languages they speak, so they may be concerned about who looks at the Accept-Language header.
  
  
• Information Obtained From the Referer Header: The Referer [sic] request header is a double-edged sword; it can be very useful to those who operate Web sites because it lets them see the sources of links to their resources. At the same time, it can be abused by those who might employ it to study users’ Web access patterns. There are also potential privacy issues that the HTTP standard raises. For example, a user might not want the name of a private document that references a public Web page to be transmitted in a Referer header.

As mentioned earlier, HTTP does not include any mechanism to protect the privacy of transmitted documents or messages. There are two different methods by which this is normally accomplished. The simplest way is to encrypt the resource on the server and supply valid decryption keys only to authorized users; even if the entire message is intercepted, the entity itself will still be secured. The level of protection here depends on the quality of the encryption.

Another more common method is to use an “add-on” protocol designed specifically to ensure the privacy of HTTP transactions. The one often used today is called Secure Sockets Layer (SSL). Servers employ SSL to protect sensitive resources, such as those associated with financial transactions. They are accessed by using the URL scheme “https” rather than “http” in a Web browser that supports the protocol. SSL was originally developed by Netscape and is now widely used across the World Wide Web.

HTTP Proxy Servers and Proxying 1 2 HTTP State Management Using "Cookies"