HTTPS - Revision history

DavidB4-bot: /* Certificate authorities */Spelling, grammar, and general cleanup, typos fixed: ’s → 's

2020-01-17T05:43:19Z

Certificate authorities: Spelling, grammar, and general cleanup, typos fixed: ’s → 's

DavidB4-bot: /* Certificate authorities */clean up, typos fixed: Hongkong → Hong Kong

2018-10-08T16:13:21Z

Certificate authorities: clean up, typos fixed: Hongkong → Hong Kong

DavidB4: update, wikilink

2017-09-13T02:36:59Z

update, wikilink

DavidB4: /* Certificate authorities */ update, StartCom being forced out of industry/business

2017-09-08T20:22:10Z

Certificate authorities: update, StartCom being forced out of industry/business

DavidB4: /* Function */ touch-up

2017-09-08T20:09:57Z

Function: touch-up

DavidB4: /* Certificate authorities */ more

2017-05-29T01:43:55Z

Certificate authorities: more

DavidB4: /* Certificate authorities */ other/invalid

2017-05-29T01:35:49Z

Certificate authorities: other/invalid

DavidB4: cert. auth

2017-05-29T01:32:38Z

cert. auth

Abcqwe: minor grammar

2017-05-29T00:26:28Z

minor grammar

DavidB4: Still not happy with it. Improving

2017-05-28T23:58:15Z

Still not happy with it. Improving

@@ Line 36: / Line 36: @@
 |StartCom** || 0.1% || 0.2%
 |-
-|Let’s Encrypt || 0.1% || 0.1%
+|Let's Encrypt || 0.1% || 0.1%
 |-
 |WISeKey Group || <0.1% || 0.1%

@@ Line 60: / Line 60: @@
 *Chunghwa Telecom
 *Izenpe
-*Hongkong Post
+*Hong Kong Post
 *Certigna
 *Microsec

@@ Line 16: / Line 16: @@
 | IdenTrust || 12% || 29.8%
 |-
-| Symantec Group || 5.5% || 13.7%
+| [[Symantec]] Group* || 5.5% || 13.7%
 |-
 |GoDaddy Group || 3% || 7.6%
@@ Line 34: / Line 34: @@
 |Actalis || 0.1% || 0.2%
 |-
-|StartCom* || 0.1% || 0.2%
+|StartCom** || 0.1% || 0.2%
 |-
 |Let’s Encrypt || 0.1% || 0.1%
@@ Line 44: / Line 44: @@
 |Other-Invalid || 35.8% ||
 |}
-''<nowiki>*</nowiki> StartCom has lost favor in the industry, and its certificates are no longer being supported by Chromium, Firefox, or Edge browsers.<ref>https://www.sslshopper.com/startcom-certificate-authority-reviews.html</ref>''<br />
+''<nowiki>*</nowiki> Symantec announced in August 2017 that they were selling their certificate service to DigiCert.<ref>https://www.symantec.com/about/newsroom/press-releases/2017/symantec_0802_01</ref>''<br />
 The following are some other known certificate authorities with a market share of less than 0.1%

@@ Line 7: / Line 7: @@
 ==Certificate authorities==
-There are many certificate authorities.  The following is a list of some of the most popularly used ones, as reported in May 2017.<ref>https://w3techs.com/technologies/overview/ssl_certificate/all</ref>
+There are many certificate authorities.  The following is a list of some of the most popularly used ones, as reported in September 2017.<ref>https://w3techs.com/technologies/overview/ssl_certificate/all</ref>
 {| class="wikitable"
 |-
 ! Name !! Usage rate !! Market Share
 |-
-| Comodo || 15.3% || 41.4%
+| Comodo || 16% || 39.7%
 |-
-| IdenTrust || 10% || 27%
+| IdenTrust || 12% || 29.8%
 |-
-| Symantec Group || 5.4% || 14.6%
+| Symantec Group || 5.5% || 13.7%
 |-
-|GoDaddy Group || 2.8% || 7.6%
+|GoDaddy Group || 3% || 7.6%
 |-
-|GlobalSign|| 1.7% || 4.7
+|GlobalSign|| 1.8% || 4.5
 |-
-|DigiCert || 0.8% || 2.2%
+|DigiCert || 0.9% || 2.2%
 |-
-|Certum || 0.2% || 0.6%
+|Certum || 0.3% || 0.6%
 |-
 |Entrust || 0.2% || 0.4%
 |-
 |Secom Trust || 0.1% || 0.3%
 |-
-|Trustwave || 0.1% || 0.3%
+|Trustwave || 0.1% || 0.2%
 |-
 |Actalis || 0.1% || 0.2%
 |-
-|Let’s Encrypt || <0.1% || <0.1%
+|StartCom* || 0.1% || 0.2%
 |-
-|WISeKey Group || <0.1% || <0.1%
+|WISeKey Group || <0.1% || 0.1%
 |-
 |Other || 25.5 ||
@@ Line 44: / Line 44: @@
 |Other-Invalid || 35.8% ||
 |}
 The following are some other known certificate authorities with a market share of less than 0.1%
 *Deutsche Telekom

@@ Line 4: / Line 4: @@
 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 he or she 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 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, he or she 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, once connected, the host and client share a symmetric key which they use from then on.  They can then communicate with reasonable certainty that their exchange is private.<br />
+Asymmetric encryption is very slow and inefficient, however. Once connected, the host and client share a symmetric key which they use from then on.  They can then communicate with reasonable certainty that their exchange is private, while benefiting from the speed and efficiency of symmetric encryption.<br />
 ==Certificate authorities==

@@ Line 42: / Line 42: @@
 |Other || 25.5 ||
 |-
-| Other-Invalid || 35.8% ||
+|Other-Invalid || 35.8% ||
 |}
 ==References==

@@ Line 2: / Line 2: @@
 ==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 he or she 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 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.<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 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, he or she 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, once connected, the host and client share a symmetric key which they use from then on.  They can then communicate with reasonable certainty that their exchange is private.<br />
 ==References==