Hypertext Transfer Protocol Secure

from Wikipedia, the free encyclopedia
HTTPS (Hypertext Transfer Protocol Secure)
Family: Internet protocol family
Operation area: encrypted data transmission
Port: 443 / TCP
HTTPS in the TCP / IP protocol stack :
application HTTP
transport SSL / TLS
TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...
Standards: RFC 2818 (HTTP Over TLS, 2000)

Hypertext Transfer Protocol Secure ( HTTPS , English for "secure hypertext transfer protocol ") is a communication protocol in the World Wide Web with which data can be transmitted securely. It represents a transport encryption.

HTTPS was developed by Netscape and published together with SSL 1.0 for the first time in 1994 with their browser.

Technically it was defined as a URI scheme , an additional layer between HTTP and TCP .

Use

HTTPS is used to establish confidentiality and integrity in communication between web server and web browser ( client ) on the World Wide Web . This is achieved through encryption and authentication , among other things .

Without encryption, data transmitted over the Internet can be read as plain text by anyone who has access to the relevant network . With the increasing spread of open (i.e. unencrypted) WLANs , the importance of HTTPS increases because it allows the content to be encrypted independently of the network.

The authentication is used so that both sides of the connection can check the identity of the connection partner when communication is established. This is to prevent man-in-the-middle attacks and, in some cases, phishing .

technology

Syntactically , HTTPS is identical to the scheme for HTTP, the additional encryption of the data is done using SSL / TLS : Using the SSL handshake protocol, the communication partners are initially identified and authenticated in a protected manner. A common symmetric session key is then exchanged with the aid of asymmetric encryption or the Diffie-Hellman key exchange. This is then used to encrypt the user data .

The standard port for HTTPS connections is 443.

In addition to the server certificates, signed client certificates according to X.509 .3 can also be created. This enables the clients to authenticate to the server, but is rarely used.

An older protocol variant of HTTPS was S-HTTP .

Client processing

With the development of HTTPS by Netscape, the protocol and the user-side client software were integrated into web browsers at an early stage. This means that no further installation of separate software is usually necessary.

SSL Symbol.png

An HTTPS connection is selected by an https URL and indicated by the SSL logo. This is shown in all common browsers as a small lock symbol in the address line.

Variants of the HTTPS selection

The decision as to whether a secure HTTPS connection is used instead of an HTTP connection can be made in different ways:

  • Only HTTPS is permitted on the server side, as is usually the case with online banking ; sometimes a selected http address is automatically forwarded to https.
  • The login is forced via HTTPS, then an HTTP cookie is set in the browser and, in order to save computing time, the further service is processed unencrypted; z. B. on eBay .
  • On the client side through HSTS : If the server only allows HTTPS (as described above), the browser can save this and will always establish a connection via HTTPS in the future. If the server is also on the HSTS preload list, the browser establishes an HTTPS connection directly on the first visit.
  • Client-side entry of the HTTPS variant or browser plug-in (eg for Firefox and Chrome " HTTPS Everywhere "), which replaces http requests with https requests for services that support both variants.

According to the original design, the client browser should first display the certificate to the user after selecting the HTTPS address . He now decides whether he trusts the certificate for this session and possibly also saves it permanently, if necessary after checking it via the specified links. Otherwise the HTTPS connection will not be established (“Leave this page” in Firefox or “Click here to leave this page” in Internet Explorer).

Pre-installed certificates

In order to avoid this query, which may be irritating for the unfamiliar, a number of root certificates have been accepted by the browser manufacturers over time, which are already entered during installation. Websites that have the corresponding certificates, as well as sub-certificates derived from them, are then accepted when they are called up without being asked. Whether or not a root certificate is known to the browser depends on the browser version; In addition, the list of certificates is partly updated online as part of the system update, for example with Microsoft Windows.

With Internet Explorer 7 , Microsoft, and shortly afterwards Mozilla with Firefox 3 , tightened the warning for unregistered certificates: If only a pop-up "Security Notice " appeared before , which differentiated according to the name, source and duration of the certificate, now the content of the website is hidden and a warning is displayed with the recommendation not to use the page. In order to be able to see this, the user must then explicitly "add an exception". A certificate that is not entered in the browser is therefore increasingly unsuitable for mass applications.

The question of which certificates are included in the browser has occasionally led to lengthy discussions in the open source community, for example between CAcert , a provider of free certificates, and the Mozilla Foundation , see CAcert (trustworthiness) .

At the end of 2015 Let's Encrypt went online, founded a. a. by Mozilla and the Electronic Frontier Foundation . Here, free certificates are offered to everyone with the aim of promoting the spread of HTTPS as a whole. However, separate software is required on the server to install and continuously update the certificates.

Server operation

An SSL library such as OpenSSL is required as software to operate an HTTPS-capable web server . This is often already supplied or can be installed as a module. The HTTPS service is usually provided on port 443.

certificate

The digital certificate for SSL that provides authentication is provided by the server: A Binärdokument which generally of a - - in turn certified Certificate Authority (CA of English certificate authority is issued) that the server and domain clearly identified. When applying, the address data and the company name of the applicant are checked.

Certificates entered in common browsers are typically offered at prices between € 15 and € 600 per year, with additional services, seals or insurances being included on a case-by-case basis. A number of certification authorities issue certificates free of charge. The certificates issued by Let's Encrypt , for example, are accepted by almost all modern browsers without an error message. CAcert also creates free certificates, but so far it has not been possible to include them in the list of certificates automatically accepted by the browser; see above . Such a certificate must therefore be imported manually by the user during client processing ; however, this behavior can also be desirable.

To explain outdated or insecure become invalid certificates are CRLs ( english list certificate revocation , CRL ) is provided. The procedure stipulates that these lists are regularly checked by browsers and certificates that are blocked in them are immediately rejected.

With the OCSP (Online Certificate Status Protocol), supplemented by SCVP (Server-based Certificate Validation Protocol), support for certificate tests can be implemented on the server side.

For attacks on the certificate system, see below .

Self-signed

A server operator can also create self-signed certificates free of charge without involving a third party. These must be confirmed manually by the browser user ('Add exception'). In this case, no third party guarantees the authenticity of the provider. Such a certificate can in turn be sent to the user in advance in a secure way and imported into his client application in order to map authenticity in another way.

Extended Validation Certificate

Against the background of increasing phishing attacks on HTTPS-secured web applications, the CA / Browser Forum was formed in 2007 in the USA , which consists of representatives from certification organizations and browser manufacturers. When it was founded, the browser manufacturers KDE, Microsoft, Mozilla and Opera were involved. In June 2007 a first common guideline was passed, the Extended Validation Certificate , EV-SSL for short in version 1.0, in April 2008 version 1.1.

A domain operator has to accept further checks for this certificate: While previously only the availability of the administrator (by phone and email) had to be checked, the postal address of the applicant is now checked and companies are checked for authorized signatories. This is also associated with significantly higher costs.

The EV certificate is noticeable to the user through the additionally displayed company of the web provider in the address line, highlighted in white on green in browsers from 2007, to the right of the site logo . Due to the lack of the additional company - which is familiar for this website - the user should now be able to recognize fake HTTPS sites quickly and, if necessary, intuitively - i.e. without special training.

IP addresses for multiple domains

For a long time it was necessary to have a separate IP address for each host name in order to operate an HTTPS web server .

This is not necessary with unencrypted HTTP: Since the browser has sent the host name in the HTTP header , several virtual web servers, each with their own host name, can be operated on one IP address, for example with Apache using the NameVirtualHost mechanism. This procedure is now used in the vast majority of domains, since the domain owner does not operate a server himself .

However, since with HTTPS the web server has to deliver a separate certificate for each host name, but the host name is only transmitted in the higher HTTP layer after the SSL handshake has taken place, declaring the host name in the HTTP header cannot be used here. This meant that it was only possible to differentiate on the basis of the IP / port combination ; a port other than 443 is again not accepted by many proxies .

Against this background, some providers used a workaround to enable their customers to use HTTPS without their own IP address, such as "shared SSL". They used wildcard certificates, which are valid for all subdomains of a domain , in connection with customer-specific subdomains. Other providers used an "SSL proxy " that directed the inquiries via a domain used by several customers.

The solution to this problem came with Server Name Indication (SNI), based on Transport Layer Security 1.2, since the host name requested by the browser can already be transmitted during the SSL handshake. With that, the other techniques mentioned above have become meaningless. The process requires up-to-date software on the server and browser side and has been supported by them since 2006.

In the case of the Apache server , the SNI processing is e.g. B. controlled by an only slightly modified configuration instruction:
<VirtualHost _default_:443>

Involvement

The integration of HTTPS into a website or application takes place in the same way as the above-mentioned variants of HTTPS selection :

  • If only HTTPS is permitted, this can be implemented by:
    • Forwarding ( HTML refresh ) or a rewrite of the URL
    • Configuration of HTML pages or scripts as mandatory SSL, with Apache for example through the instruction SSLRequireSSLin .htaccess . If such a page is called via HTTP, the server generates a '403 - Forbidden' HTTP error code .
  • The user is informed of the possibility of using SSL through a corresponding link.
    • In some cases, especially during the introduction of HTTPS, there is no application via a link. The user can only switch to HTTPS manually by adding the "s" after "http" to the URL.
  • Script-controlled generation of HTTPS links to direct the user to an HTTPS page for certain work steps or outputs. You can then check in the script whether it was called via HTTPS, for example with PHP using the condition:$_SERVER['HTTPS']=='on'

Changeover

With increasing CPU performance and security awareness, the requirement regularly arises to convert a website that was previously based on HTTP to HTTPS. In the case of the Stack Overflow website with a large number of users and services, this process takes several years and is not completed as of March 2017. In doing so, u. a. worked on the following topics:

  • Avoiding the integration of unencrypted data (media data, style sheets, etc.) in an encrypted page (so-called mixed content ). Otherwise browser warnings such as 'Part of this page is not secure' will be issued or data will not be loaded.
  • The entire infrastructure must be converted to SSL, including load balancers and proxies
  • Organization of the certificates, if necessary for a large number of subdomains
  • Conversion of code of your own web application in which HTTP is hard-coded
  • Converting the old and checking the new user code, which may use HTTP
  • Quality inspection
  • Implementation of ongoing sessions without losing their content (24/7 operation)

power

When the connection is established, the server defines an encryption algorithm. In theory, the server should orientate itself to the wishes of the client. In order to save computing time, however , stream ciphers are preferred on servers with high data traffic , as these are less computationally intensive than block ciphers like AES or Camellia . Many of the methods that have been used for a long time, such as RC4, are considered insecure and have therefore no longer been supported by major web browsers since 2016 .

And hardware SSL accelerator (used to relieve the server CPU SSL accelerators ) offered: PCI cards with special optimized processors, which are addressed in the SSL library. There are also stand-alone devices, mostly in rack design, that automatically encrypt parts of the HTTP data stream. Furthermore, servers are available with programmable computing units that reach higher with corresponding SSL libraries performance than comparable consuming Universal CPUs, the MAU ( Modular Arithmetic Unit ) from Sun . This special hardware is in close competition with the constant development of the multiprocessor and multi-core systems of the large CPU manufacturers Intel and AMD.

In 2010, for example, encryption in Gmail caused less than 1% of the processor load, less than 10 KB of memory required per connection and less than 2% of the network traffic . Ten years ago, the computing effort of the encryption was still a heavy burden on the server.

Attacks and vulnerabilities

With the general increase in knowledge about HTTPS technology, attacks on SSL-secured connections have also increased. In addition, gaps in implementation have become known through research. A basic distinction must be made between weak points in the encryption itself and in the certificate system. In 2013, in connection with the global surveillance and espionage affair, it became known that the NSA used both channels of attack to gain access to encrypted connections.

Encryption

The encryption methods used by SSL are checked regularly, regardless of their purpose, and are considered mathematically secure, i.e. In other words, they cannot theoretically be broken with the techniques known today. The reliability of the algorithms is checked regularly through competitions among cryptologists . Support for outdated encryption methods, which are no longer considered secure according to the current state of the art, are regularly removed from the specifications and the implementations, and new methods are added.

Problems arose several times in the past due to incorrect implementation of the cryptology. In particular, vulnerabilities in the widespread OpenSSL library such as Heartbleed received a great deal of public attention.

Since users usually do not explicitly request an encrypted connection by specifying the HTTPS protocol ( https: // ) when accessing a website, an attacker can prevent encryption of the connection before initialization and a man-in-the-middle attack To run. The HTTP Strict Transport Security (HSTS) standard was developed to protect against such attacks .

The HTTP Strict Transport Security or HSTS procedure was introduced in 2012 specifically to protect against downgrade attacks against encryption and session hijacking . It is activated by an HSTS header on the part of the server, whereupon the browser u. a. http can be converted into https URLs.

Certificate system

SSL connections are fundamentally at risk from man-in-the-middle attacks , in which the attacker intercepts the data traffic between client and server, for example by pretending to be an intermediate point. A number of attack methods require that the attacker is in the victim's network. In turn, DNS spoofing does not meet these requirements.

In order to pretend to be a (different) server, the attacker must also show a certificate. He can do this, for example, if he succeeds in breaking into the system of a certification authority, or if he otherwise comes into possession of a certificate with which any other certificate can be issued. In the case of influential attackers, such as government agencies, in particular, such opportunities may exist, as state certification bodies sometimes also exist. HTTP public key pinning and certificate transparency are designed to make such attacks more difficult.

Phishing and HTTPS

A disadvantage of the automatic confirmation of the certificates is that the user is no longer aware of an HTTPS connection. This has recently been exploited in phishing attacks that simulate online banking applications , for example, and simulate a secure connection for the user in order to “fish” the PIN / TAN codes entered . In response, affected companies advised their customers not to click any links from emails and only enter https URLs manually or by bookmarking .

Because of the sometimes superficial checks when issuing certificates, the browser manufacturers introduced the extended-validation-Cert , see above .

Mixed content

Reloading unencrypted resources enables an attacker to smuggle malicious code into the originally encrypted website using a man-in-the-middle attack . Therefore, current versions of common web browsers block the reloading of unencrypted resources by default. Likewise, with an HTTP cookie used for both encrypted and unencrypted connections, there is a risk of session hijacking , even if the authentication was carried out via an encrypted connection.

MD5 vulnerability

At the 25th Chaos Communication Congress in Berlin in December 2008, a successful attack on the SSL certificate system was published. In international cooperation between cryptologists and with the use of specially programmed hardware - a cluster of 200 Playstation 3 game consoles - it was possible to generate a collision in the MD5 algorithm on the basis of which an attacker could issue any certificates himself. The use of the MD5 algorithm was previously advised against in specialist circles; it cannot be used with EV certificates anyway. Most web browsers have stopped accepting MD5 certificates since 2011. In order to avoid similar problems, the browser manufacturers announced that they would only support SHA1 certificates for a limited time.

Specifications

Web links

Individual evidence

  1. ↑ Preloading HSTS .
  2. ↑ apache.org: Apache 2.5 OCSP Stapling , accessed July 23, 2017.
  3. ↑ https://web.archive.org/web/20070202031218/http://www.cabforum.org/forum.html
  4. ↑ Internet Engineering Task Force: RFC 3546 , June 2003, accessed March 10, 2017.
  5. ↑ digitalocean.com: How To Set Up Multiple SSL Certificates on One IP with Apache on Ubuntu 04/12 , October 19, 2012, accessed March 9, 2017.
  6. ↑ nickgeoghegan.net: Enabling Server Name Includes on Debian Squeeze , accessed July 23, 2017.
  7. ↑ meta.stackexchange.com: Network-wide HTTPS: It's time , accessed March 9, 2017.
  8. ↑ nickcraver.com: Stackoverflow.com: the road to SSL , accessed on 9 March 2017th
  9. ↑ Description of mixed content at www.w3.org.
  10. ↑ Emil Protalinski: Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year , VentureBeat, September 1, 2015.
  11. ↑ Quad Core Intel Xeon SSL Performance on anandtech.com, December 27, 2006.
  12. ^ A b Adam Langley, Nagendra Modadugu, Wan-Teh Chang: Overclocking SSL. In: ImperialViolet. Adam Langley's weblog. June 25, 2010, accessed October 23, 2014 .
  13. ↑ Example: Daniel Berger: Firefox 39 removes SSLv3 and RC4. In: Heise online . July 3, 2015, accessed October 22, 2015 . Daniel Berger: Firefox 27 encrypted with TLS 1.2. In: Heise online . February 4, 2014, accessed October 22, 2015 .
  14. ^ Daniel Bachfeld: Black Hat: New attack methods on SSL presented. In: Heise online Security. February 19, 2009, accessed October 25, 2015 .
  15. ↑ EFF doubts SSL's security against eavesdropping on heise security, accessed on June 28, 2013.
  16. ↑ 25C3: Successful attack on the SSL certificate system . From heise.de, December 30, 2008, accessed January 3, 2013.
  17. ↑ Apple IOS5 , Firefox 16 , Microsoft Internet Explorer .
  18. ↑ Ivan Ristic: SHA1 Deprecation: What You Need to Know .