Difference between revisions of "HTTPS"

From Conservapedia
Jump to: navigation, search
(Function: name of attack type)
(Still not happy with it. Improving)
Line 1: Line 1:
'''HTTPS''' (HyperText Transfer Protocol Secure) is a secured version of [[HTTP]], a text-based data transfer protocol using the request-and-respond method. While traditional HTTP communicates with plain text (which can be intercepted and read), HTTPS using a form of [[Public-key encryption]] to help provide [[Internet security]] for the information which is transferred.<ref>https://www.howtogeek.com/181767/htg-explains-what-is-https-and-why-should-i-care</ref>
+
'''HTTPS''' (HyperText Transfer Protocol Secure) is a secured version of [[HTTP]], a text-based data transfer protocol used by websites. While traditional HTTP communicates with plain text (which can be intercepted and read), HTTPS using a form of [[Public-key encryption]] to help provide [[Internet security]] for the information which is transferred.<ref>https://www.howtogeek.com/181767/htg-explains-what-is-https-and-why-should-i-care</ref>
  
 
==Function==
 
==Function==
 
Since HTTP packets can be easily intercepted and read, the primary goal of HTTPS is to encrypt this communication without significantly impacting the functionality of the World Wide Web.  Using asymmetric encryption (SSL or TLS), the server and client connect to each other.  The client sends a request for the server's public key, which the server sends. The client also supplies its public key, so each can communicate with the other securely.  Each party can also verify the sender of each message, because each message is encrypted with the sender's private key, which only they should posses.<ref>https://www.instantssl.com/ssl-certificate-products/https.html</ref><br />
 
Since HTTP packets can be easily intercepted and read, the primary goal of HTTPS is to encrypt this communication without significantly impacting the functionality of the World Wide Web.  Using asymmetric encryption (SSL or TLS), the server and client connect to each other.  The client sends a request for the server's public key, which the server sends. The client also supplies its public key, so each can communicate with the other securely.  Each party can also verify the sender of each message, because each message is encrypted with the sender's private key, which only they should posses.<ref>https://www.instantssl.com/ssl-certificate-products/https.html</ref><br />
However, there is still a flaw in this system alone.  During the initial exchange, an attacker could intercept the server and client public keys, and send his own.  The client would never know, but the attacker has essentially tapped into the entire exchange using this method, known as a "man-in-the-middle attack."  To deal with this issue, servers using HTTPS have their public keys indexed by certificate authorities.  When a client attempts to visit a site using HTTPS, the client checks the supplied public key against the one on file with a certificate authority.  If they match, the process continues and the key as saved on the client's device for future use.  If not, the user is shown a security warning.  An increasing number of browsers even block access altogether in case of a supplied key/certificate mismatch.<ref>http://www.helpwithpcs.com/jargon/http.htm</ref><br />
+
However, there is still a flaw in this system alone.  During the initial exchange, an attacker can intercept the server and client public keys, and send his own in their placeNeither party would ever know, but the attacker has essentially tapped into the entire exchange using this method, known as a "man-in-the-middle attack."  To deal with this issue, servers using HTTPS have their public keys indexed by certificate authorities.  When a client attempts to visit a site using HTTPS, the client checks the supplied public key against the one on file with a certificate authority.  If they match, the process continues and the key as saved on the client's device for future use.  If not, the user is shown a security warning.  An increasing number of browsers even block access altogether in case of a supplied key/certificate mismatch.<ref>http://www.helpwithpcs.com/jargon/http.htm</ref><br />
 
Asymmetric encryption is very slow and inefficient, however, so once connected, the host and client share a symmetric key which they use from then on.  Now they can communicate with reasonable certainty that their exchange is private.<br />
 
Asymmetric encryption is very slow and inefficient, however, so once connected, the host and client share a symmetric key which they use from then on.  Now they can communicate with reasonable certainty that their exchange is private.<br />
  

Revision as of 23:58, May 28, 2017

HTTPS (HyperText Transfer Protocol Secure) is a secured version of HTTP, a text-based data transfer protocol used by websites. While traditional HTTP communicates with plain text (which can be intercepted and read), HTTPS using a form of Public-key encryption to help provide Internet security for the information which is transferred.[1]

Function

Since HTTP packets can be easily intercepted and read, the primary goal of HTTPS is to encrypt this communication without significantly impacting the functionality of the World Wide Web. Using asymmetric encryption (SSL or TLS), the server and client connect to each other. The client sends a request for the server's public key, which the server sends. The client also supplies its public key, so each can communicate with the other securely. Each party can also verify the sender of each message, because each message is encrypted with the sender's private key, which only they should posses.[2]
However, there is still a flaw in this system alone. During the initial exchange, an attacker can intercept the server and client public keys, and send his own in their place. Neither party would ever know, but the attacker has essentially tapped into the entire exchange using this method, known as a "man-in-the-middle attack." To deal with this issue, servers using HTTPS have their public keys indexed by certificate authorities. When a client attempts to visit a site using HTTPS, the client checks the supplied public key against the one on file with a certificate authority. If they match, the process continues and the key as saved on the client's device for future use. If not, the user is shown a security warning. An increasing number of browsers even block access altogether in case of a supplied key/certificate mismatch.[3]
Asymmetric encryption is very slow and inefficient, however, so once connected, the host and client share a symmetric key which they use from then on. Now they can communicate with reasonable certainty that their exchange is private.

References