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.
|
|
|
|
HTTP Security and Privacy
(Page 2 of 2)
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.
Methods for Ensuring Privacy in HTTP
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.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|