2,438
edits
Changes
no edit summary
|-
| 1995 || {{w|February}} || Standard || SSL v2.0 || Protocol || SSL v2.0 is released. It has a number of security flaws. See [[w:Transport Layer Security#SSL_1.0.2C_2.0_and_3.0]].
|-
| 1995 || {w|July}} || Server hosting || Netscape || Commercial offering || ''Fortune'' reports that Netscape charges $1,495 for a server and $5,000 for a server with secure communication (i.e., serving traffic over HTTPS).<ref>{{cite web|url = http://fortune.com/2012/02/05/the-rise-of-netscape/|title = The rise of Netscape|last = Sprout|first = Alison|date = July 1, 1995|accessdate = March 11, 2018}}</ref><ref name=jeff>{{cite web|url = https://www.jefftk.com/p/history-of-https-usage|title = History of HTTPS Usage|date = March 8, 2018|accessdate = March 11, 2018|last = Kaufman|first = Jeff}}</ref>
|-
| 1995 || {{w|September 19}} || Bugfix || || Vulnerability exploit || Two graduate students at the University of California, Berkeley discover a security vulnerability with Netscape Navigator, that also affects HTTPS sites and risks credit card transactions being eavesdropped on.<ref>{{cite web|url = http://www.cnn.com/TECH/9509/netscape_flaw/index.html|title = Netscape: Internet security flaw can be fixed.|date = September 19, 1995|accessdate = March 11, 2018}}</ref><ref>{{cite web|url = http://query.nytimes.com/gst/fullpage.html?res=990CEFDC1131F935A25753C1A963958260&pagewanted=all|title = The New Watchdogs of Digital Commerce|date = October 16, 1995|accessdate = March 11, 2018|publisher = ''New York Times''|last = Markoff|first = John}}</ref><ref name=jeff/>
|-
| 1996 || || Standard || SSL v3.0 || Protocol || SSL v3.0 is released and its specification is drafted. IETF would publish this draft as a historical document in 2011.<ref>{{Cite web|url = https://tools.ietf.org/html/rfc6101|title = The Secure Sockets Layer (SSL) Protocol Version 3.0|date = August 1, 2011|accessdate = November 23, 2017|publisher = [[Internet Engineering Task Force]]}}</ref>
| 2003 || {{dts|June}} || Standard || SNI || Protocol || RFS 3546 of the IETF describes a number of augmentations to TLS, including {{w|Server Name Indication}} (SNI).<ref>{{cite web|url = https://tools.ietf.org/html/rfc3546|title = Transport Layer Security (TLS) Extensions|date = June 1, 2003|accessdate = November 20, 2017|publisher = Internet Engineering Task Force}}</ref>
|-
| 2004 || {{dts|April 1}} || Webmail || Google (Gmail) || HTTPS availability || Gmail, Google's web-based email service, launches. The service is available over HTTPS right from the time of launch.<ref name=jeff/>|-| 2004 || {{dts|April 14}} || Bugfix || || Vulnerability exploit || Microsoft issues a fix for a bug in its SSL library that allows remote attackers to gain control of unpatched Windows 2000 and Windows NT4 servers offering encrypted services over the internet.<ref>{{cite web|url = https://news.netcraft.com/archives/2004/04/14/microsoft_ssl_vulnerability_gives_attackers_opportunity_to_gain_control_of_leading_banking_sites.html|title = Microsoft SSL Vulnerability gives attackers opportunity to gain control of leading banking sites|date = April 14, 2004|accessdate = March 11, 2018|publisher = Netcraft}}</ref>|-|2005 || {{dts|April 20}} || || || || A blog post by Microsoft argues that using non-HTTPS login pages is insecure, even if the form submission is to a HTTPS page.<ref>{{cite web|url = https://blogs.msdn.microsoft.com/ie/2005/04/20/tls-and-ssl-in-the-real-world/|title = TLS and SSL in the real world|date = April 20, 2005|accessdate = March 11, 2018}}</ref><ref name=jeff/>|-| 2005 || || || || || The {{w|CA/Browser Forum}} is founded. Ir It is a voluntary consortium of certification authorities, vendors of Internet browser software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v.3 digital certificates that chain to a trust anchor embedded in such applications.
|-
| 2006 || {{dts|April}} || Standard || TLS 1.1 || Protocol || RFC 4346 defines TLS 1.1, the next version of TLS after TLS 1.0.<ref>{{cite web|url = https://tools.ietf.org/html/rfc4346|title = The Transport Layer Security (TLS) Protocol Version 1.1|date = April 1, 2006|accessdate = November 23, 2017|publisher = Internet Engineering Task Force}}</ref>
|-
| 2008 || {{dts|July 24}} || Webmail || Google (Gmail) || Opt-in HTTPS-only || Google adds a setting in Gmail for users to always use HTTPS. Even before this, users could (since the inception of Gmail) access it securely by explicitly typing https:// in the browser. With the new setting, users who have opted in to it will be redirected from HTTP to HTTPS.<ref>{{cite web|url = https://gmail.googleblog.com/2008/07/making-security-easier.html|title = Making security easier|date = July 24, 2008|accessdate = November 19, 2017|last = Rideout|first = Ariel|publisher = Google}}</ref><ref name=jeff/>
|-
| 2008 || {{dts|August}} || Standard || TLS 1.2 || Protocol || RFC 5246 defines TLS 1.2, the next version of TLS after TLS 1.1.<ref>{{Cite web|url = https://tools.ietf.org/html/rfc5246|title = The Transport Layer Security (TLS) Protocol Version 1.2|date = August 1, 2008|accessdate = November 23, 2017|publisher = Internet Engineering Task Force}}</ref>
|-
| 2010 || {{dts|January 12}} || Webmail|| Google (Gmail) || Default HTTPS-only || Google switches all Gmail users to redirect to HTTPS; users can change their setings to not redirect to HTTPS. Previously, the default option for this setting was to not redirect, and users had to explicitly choose the option to redirect HTTP to HTTPS.<ref>{{cite web|url = https://gmail.googleblog.com/2010/01/default-https-access-for-gmail.html|title = Default https access for Gmail|date = January 12, 2010|accessdate = November 19, 2017|publisher = Google|last = Schillace|first = Sam}}</ref><ref name=jeff/>|-| 2010 || {{dts|May 21}} || Search engine || Google Search || HTTPS availability || Google makes search available on SSL at https://www.google.com. However, on June 25, they announced that they are moving encrypted search to https://encrypted.google.com because of challenges reported by school districts.<ref>{{cite web|url = https://googleblog.blogspot.com/2010/05/search-more-securely-with-encrypted.html|title = Search more securely with encrypted Google web search|date = May 21, 2010|accessdate = March 11, 2018|publisher = Google Official Blog|last = Roseman|first = Evan}}</ref><ref name=jeff/>
|-
| 2010 || {{dts|June 17}} || Browser extension || HTTPS Everywhere || Security improvement || The {{w|Electronic Frontier Foundation}} and {{w|The Tor Project, Inc}} launch {{w|HTTPS Everywhere}}, a {{w|Firefox}} extension, to make Firefox use HTTPS where possible.<ref>{{cite web|url = https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension|title = Encrypt the Web with the HTTPS Everywhere Firefox Extension|last = Eckersley|first = Peter|date = June 17, 2010|accessdate = November 19, 2017|publisher = Electronic Frontier Foundation}}</ref> The extension would evolve over the coming years. As of 2017, it is supported on Firefox, Chrome, and Opera.<ref name=https-everywhere>{{cite web|url = https://www.eff.org/https-everywhere|title = HTTPS Everywhere|accessdate = November 19, 2017}}</ref>
| 2011 || {{dts|January}} || Website || Facebook || Opt-in HTTPS-only || {{w|Facebook}} begins allowing logged-in users to opt in to have all their Facebook browsing encrypted by HTTPS.<ref name=facebook-https-default>{{cite web|url = https://techcrunch.com/2012/11/18/facebook-https/|title = Facebook Could Slow Down A Tiny Bit As It Starts Switching All Users To Secure HTTPS Connections|last = Constine|first = Josh|date = November 18, 2012|accessdate = November 19, 2017|publisher = ''TechCrunch''}}</ref>
|-
| 2011 || {{dts|January}} || Standard || OCSP stapling || || RFC 6066, introducing OCSP stapling, is published.<ref>{{cite web|url = https://tools.ietf.org/html/rfc6066|title = Transport Layer Security (TLS) Extensions: Extension Definitions|date = January 1, 2011|accessdate = November 19, 2017}}</ref> OCSP stapling is an alternative approach to the {{W|Online Certificate Status Protocol}} llows that allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the certificate authority. RFC 6961 would cover the case of multiple OCSP stapling.<ref>{{cite web|url = https://tools.ietf.org/html/rfc6961|title = The Transport Layer Security (TLS) Multiple Certificate Status Request Extension|date = June 1, 2013|accessdate = November 19, 2017}}</ref>
|-
| 2011 || {{dts|March 15}} || Website || Twitter || Opt-in HTTPS-only || {{w|Twitter}} begins allowing logged-in users to opt in to have all their Twitter browsing encrypted by HTTPS.<ref name=twitter-https-optin>{{cite web|url = https://blog.twitter.com/official/en_us/a/2011/making-twitter-more-secure-https.html|title = Making Twitter more secure: HTTPS|date = March 15, 2011|accessdate = November 19, 2017|publisher = Twitter}}</ref>
| 2018 || {{dts|July}} (planned date), February 8 (announcement) || Browser || Chrome || Security warning || Google Chrome announces that starting with Chrome 68, which will be released in July, all plain HTTP sites will be marked as not secure.<ref>{{cite web|url = https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html|title = A secure web is here to stay|date = February 8, 2018|accessdate = February 11, 2018|publisher = Google Security Blog|last = Schechter|first = Emily}}</ref><ref>{{cite web|url = https://techcrunch.com/2018/02/08/chrome-will-soon-mark-all-unencrypted-pages-as-not-secure/|title = Chrome will soon mark all unencrypted pages as ‘not secure’|last = Lardinois|first = Frederic|date = February 8, 2018|accessdate = February 11, 2018|publisher = ''TechCrunch''}}</ref><ref>{{cite web|url = https://arstechnica.com/gadgets/2018/02/from-july-on-chrome-will-brand-plain-old-http-as-not-secure/|title = From July on, Chrome will brand plain old HTTP as “Not secure”. The "Not secure" label will go where the padlock would go for an encrypted connection.|last = Bright|first = Peter|date = February 9, 2018|accessdate = February 11, 2018|publisher = ''ArsTechnica''}}</ref>
|}
== See also ==
* [https://www.jefftk.com/p/history-of-https-usage History of HTTPS Usage] by Jeff Kaufman
== References ==
{{reflist|30em}}
