The Future "Web on Speed" - Revision history

Wolfm at 11:36, 5 March 2019

2019-03-05T11:36:27Z

← Older revision		Revision as of 11:36, 5 March 2019
Line 76:		Line 76:
	Of note is the fact, that ''h2Push'' (speculative server push mode) is generally enabled by default in most implementations.		Of note is the fact, that ''h2Push'' (speculative server push mode) is generally enabled by default in most implementations.

	For example: in ~~Apace~~ resources may be marked for speculative server push by simply adding the following to the ''mod_headers'':		For example: in Apache resources may be marked for speculative server push by simply adding the following to the ''mod_headers'':
	<Location $/path/to/resource/$>		<Location $/path/to/resource/$>
	Header add Link "</file/to/preload.css>; rel=preload"		Header add Link "</file/to/preload.css>; rel=preload"
Line 102:		Line 102:

	With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.		With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.
	It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]) and highly builds upon hardware implementations of ''AES_GCM'' that were originally created in support of ''IPSEC''. It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.		It promises fewer context switches and file copies to be necessary for the encryption process or decryption process respectively, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]) and highly builds upon hardware implementations of ''AES_GCM'' that were originally created in support of ''IPSEC''. It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.

	Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function ''sendfile()'', which allows file transfers without the pictured copy round trip of a given file through the user space. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]		Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function ''sendfile()'', which allows file transfers without the pictured copy round trip of a given file through the user space. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]

Muelerse at 13:06, 4 March 2019

2019-03-04T13:06:02Z

← Older revision		Revision as of 13:06, 4 March 2019
Line 106:		Line 106:
	Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function ''sendfile()'', which allows file transfers without the pictured copy round trip of a given file through the user space. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]		Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function ''sendfile()'', which allows file transfers without the pictured copy round trip of a given file through the user space. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]
	Within a year however, they managed to reach a 247.06% speed increase (to about 29.5Gbps) on the baseline OpenSSL traffic when employing a modified version of ''OpenSSL''. Using highly optimized libraries researches at Netflix Inc. even managed to increase that percentage to 320.59% (~35.75Gbps). With these speeds the network interfaces once again become the limiting bottlenecks, even though the connection is now ''TLS'' encrypted. [https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf]		Within a year however, they managed to reach a 247.06% speed increase (to about 29.5Gbps) on the baseline OpenSSL traffic when employing a modified version of ''OpenSSL''. Using highly optimized libraries researches at Netflix Inc. even managed to increase that percentage to 320.59% (~35.75Gbps). With these speeds the network interfaces once again become the limiting bottlenecks, even though the connection is now ''TLS'' encrypted. [https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf]

			==Conclusions==
			While ''HTTP/2'' did not fully address issues, it still improves significantly on previous versions. Especially in combination with ''TLS 1.3'' it is likely to increase both security, as well as integrity of web based communications. ''KTLS'' also supports one of the employed ''TLS 1.3'' and could significantly speed up encrypted file transfers as well.

Muelerse at 12:54, 4 March 2019

2019-03-04T12:54:18Z

← Older revision		Revision as of 12:54, 4 March 2019
Line 95:		Line 95:
	Even though, there are several points in which the specification falls considerably short of the promised improvements on previous versions, it is required by design, that all ''HTTP/2'' implementations willing to communicate using ''TLS 1.2'' (or greater) to include support of the		Even though, there are several points in which the specification falls considerably short of the promised improvements on previous versions, it is required by design, that all ''HTTP/2'' implementations willing to communicate using ''TLS 1.2'' (or greater) to include support of the
	* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256		* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
			''TLS'' mode using P-256ec.
	~~''TLS'' mode using P-256ec.~~ This mode is mandated by both the new ''TLS 1.3'' version and ''KTLS'' as currently included in the ''Linux'' kernel. The German ''BSI'' is explicitly recommending use of this cipher suite up until 2025+ in its [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf;jsessionid=C73C09A84ECE395D5077EA87768F3A0F.1_cid341?__blob=publicationFile&v=7 TR-02102-2] document (as of Jan. 2019).		This mode is mandated by both the new ''TLS 1.3'' version and ''KTLS'' as currently included in the ''Linux'' kernel. The German ''BSI'' is explicitly recommending use of this cipher suite up until 2025+ in its [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf;jsessionid=C73C09A84ECE395D5077EA87768F3A0F.1_cid341?__blob=publicationFile&v=7 TR-02102-2] document (as of Jan. 2019).

	==KTLS==		==KTLS==
			[[File:DataFlowTLS.png\|thumb\|Data flow in TLS using OpenSSL]]

	With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.		With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.
	It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]). It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.		It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]) and highly builds upon hardware implementations of ''AES_GCM'' that were originally created in support of ''IPSEC''. It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.

	Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70%. The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase. ~~[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]~~ ~~Within~~ a ~~year~~ ~~however,~~ ~~they~~ ~~managed~~ to ~~reach~~ a ~~247.06%~~ ~~speed~~ ~~increase~~ on the ~~baseline~~ ~~OpenSSL~~ ~~traffic~~, ~~and~~ ~~using~~ ~~highly~~ ~~optimized~~ ~~libraries~~ ~~even~~ ~~managed~~ to ~~increase~~ ~~that~~ ~~percentage~~ to ~~320.59%~~. [~~https~~://~~people~~.~~freebsd~~.~~org~~/~~~rrs~~/~~asiabsd_tls_improved~~.pdf]		Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function ''sendfile()'', which allows file transfers without the pictured copy round trip of a given file through the user space. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf]
			Within a year however, they managed to reach a 247.06% speed increase (to about 29.5Gbps) on the baseline OpenSSL traffic when employing a modified version of ''OpenSSL''. Using highly optimized libraries researches at Netflix Inc. even managed to increase that percentage to 320.59% (~35.75Gbps). With these speeds the network interfaces once again become the limiting bottlenecks, even though the connection is now ''TLS'' encrypted. [https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf]

Muelerse: Added HTTP/2 -- future proofing

2019-03-04T10:29:42Z

Added HTTP/2 -- future proofing

← Older revision		Revision as of 10:29, 4 March 2019
Line 10:		Line 10:
	==HTTP/2==		==HTTP/2==
	''HTTP'' is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: ''HTTP/1.0'' as described in [https://tools.ietf.org/html/rfc1945 RFC1945], which then was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (even though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]). As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.		''HTTP'' is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: ''HTTP/1.0'' as described in [https://tools.ietf.org/html/rfc1945 RFC1945], which then was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (even though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]). As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.

			The specification allows for two modes
			* ''h2'' (''HTTP/2'' over ''TLS''),
			* ''h2c'' (''HTTP/2'' over ''TCP'')
			and it also defines 10 frame types:
			* HEADERS,
			* CONTINUATION,
			* SETTINGS,
			* PRIORITY,
			* PUSH_PROMISE,
			* DATA,
			* WINDOW_UPDATE,
			* PING,
			* GOAWAY,
			* RST_STREAM.

	====Promises====		====Promises====
Line 68:		Line 83:
	In H2O servers the feature is similarly on by default. H2O does improve on the speculative push a bit, by employing a feature called ''CASPer'' (Cache-Aware Server-Push). This feature tracks the clients cache states and the presence of resources in them by way of cookies. If a resource marked as ''preload'' is not present within the clients' cache push the resources specified with the link header.		In H2O servers the feature is similarly on by default. H2O does improve on the speculative push a bit, by employing a feature called ''CASPer'' (Cache-Aware Server-Push). This feature tracks the clients cache states and the presence of resources in them by way of cookies. If a resource marked as ''preload'' is not present within the clients' cache push the resources specified with the link header.

	Generally, it is advised by software providers to push contents which were previously inlined in ''HTTP/1.1''.		Generally, it is advised by software providers to push contents which were previously inlined in ''HTTP/1.1''. However, if configured incorrectly, use of ''HTTP/2'' might actually increase network usage, as possibly too much of the content is pushed automatically (especially: if the server push does in fact not take the client side caches into account).

	====Possible shortcommings in the RFC====		====Possible shortcommings in the RFC====

	* Possible Head-Of-Line-Blocking issues are not handled by the RFC and must be dealt with by the implementation. This might lead to inconsistent behaviour regarding this issue.		* Possible Head-Of-Line-Blocking issues are not handled by the RFC and must be dealt with by the implementation. This might lead to inconsistent behaviour regarding this issue.
	* In the RFC the ''Window-Update'' message seems to be used a bit excessively for the specified goal of reducing/minimizing network usage. A delayed (i.e. aggregated) ''Window-Update'' message might be advantageous to further reduce network traffic.		* In the RFC the ''Window-Update'' message seems to be used a bit excessively for the specified goal of reducing/minimizing network usage. A delayed (i.e. aggregated) ''Window-Update'' message might be advantageous to further reduce network traffic (see also: delayed ACK's in ''TCP'').
	* Cipher spec renegotiation is disabled, which might lead to long lived connections that actually stall due to limitations on the number of possible messages using that cipher. This in turn might lead fallbacks to ''HTTP/1.1''.		* Cipher spec renegotiation is disabled, which might lead to long lived connections that actually stall due to limitations on the number of possible messages using that cipher. This in turn might lead fallbacks to ''HTTP/1.1''.
	* The designed backward compatibility allows for selection of possibly blacklisted cipher-suites, should the application protocol and the cipher-suite be selected independent of one another.		* The designed backward compatibility allows for selection of possibly blacklisted cipher-suites, should the application protocol and the cipher-suite be selected independent of one another.
	* Further security considerations can be found in ''RFC 7540'' in section 10.		* Further security considerations can be found in ''RFC 7540'' in section 10.

			====Future proofing====
			Even though, there are several points in which the specification falls considerably short of the promised improvements on previous versions, it is required by design, that all ''HTTP/2'' implementations willing to communicate using ''TLS 1.2'' (or greater) to include support of the
			* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
			''TLS'' mode using P-256ec. This mode is mandated by both the new ''TLS 1.3'' version and ''KTLS'' as currently included in the ''Linux'' kernel. The German ''BSI'' is explicitly recommending use of this cipher suite up until 2025+ in its [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf;jsessionid=C73C09A84ECE395D5077EA87768F3A0F.1_cid341?__blob=publicationFile&v=7 TR-02102-2] document (as of Jan. 2019).

	==KTLS==		==KTLS==
	With Linux kernel 4.13 (3.9.2017) ''Kernel ~~TLS~~'' was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was ~~completed~~ by adding the so far missing ~~decryption~~ ~~side of things~~.		With Linux kernel 4.13 (3.9.2017) ''Linux Kernel Transport Layer Security'' (or ''KTLS'' for short) was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was significantly updated by adding the so far missing ''TLS'' decryption.

	It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]). It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.		It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]). It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.

Muelerse: Added H2 subsections Server-side and Possible shortcommings in the RFC

2019-03-01T10:26:14Z

Added H2 subsections Server-side and Possible shortcommings in the RFC

@@ Line 9: / Line 9: @@
 ==HTTP/2==
-''HTTP'' is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: ''HTTP/1.0'' as described in [https://tools.ietf.org/html/rfc1945 RFC1945] and was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]).  As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.
+''HTTP'' is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: ''HTTP/1.0'' as described in [https://tools.ietf.org/html/rfc1945 RFC1945], which then was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (even though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]).  As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.
 ====Promises====
@@ Line 51: / Line 51: @@
 |}
-It is notable, that while ''h2c'' for unencrypted traffic is specified, all major browsers implement only the ''h2''. Thus encrypted traffic is the ''de facto'' standard when using ''HTTP/2''.
+It is notable, that while ''h2c'' for unencrypted traffic is specified, all major browsers only implement the ''h2'' protocol part . Thus encrypted traffic is the ''de facto'' standard when using ''HTTP/2''.
 ==KTLS==

Muelerse: First draft

2018-10-09T11:34:02Z

First draft

New page

==Motivation==

The advent of [https://tools.ietf.org/html/rfc8446 TLS1.3], of [https://tools.ietf.org/html/rfc7540 HTTP/2], and of [https://netdevconf.org/1.2/papers/ktls.pdf KTLS] begs the questions:
* Where does the standardization lead?
* Are there already working implementations?
* Does this mean faster and more secure web browsing for all?

This article will mainly talk about ''HTTP/2'' and in part about ''KTLS''.

==HTTP/2==
''HTTP'' is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: ''HTTP/1.0'' as described in [https://tools.ietf.org/html/rfc1945 RFC1945] and was updated to version ''HTTP/1.1'' in 1999 in [https://tools.ietf.org/html/rfc2616 RFC2616] (though it was first proposed in 1997 [https://tools.ietf.org/html/rfc2068]). As of May 2015 ''HTTP/2'' is specified in the above mentioned RFC7540.

====Promises====
The new ''HTTP'' version addresses a number of issues present in previous versions:

* Multiplexing of streams is now possible in '''one''' connection
* Prioritization of streams allows for faster handling of more important requests
* Upgrade mechanism allows for older systems in the network that do not understand ''HTTP/2''
* Compression of verbose header fields is possible
* Use of binary message framing further minimizes network usage
* Speculative server push mode for reduced need of inlined content and increased cacheablity

====Implementations====
As of approximately mid-2015, many consumer products offer support for ''HTTP/2'' in their respective implementations. The following table gives an overview of tools that include support; it does not claim to be complete:

{| class="wikitable"
|-
! Browser Software
! Server-side Software
! CDN's
|-
| Chromium
| Apache
| Akamai
|-
| Edge (and Internet Explorer)
| H2O
| AWS
|-
| Firefox
| Microsoft Server
| Microsoft Azure
|-
| Opera
| nginx
| Cloudflare
|-
| Safari
| SuaveIO
| Fastly
|}

It is notable, that while ''h2c'' for unencrypted traffic is specified, all major browsers implement only the ''h2''. Thus encrypted traffic is the ''de facto'' standard when using ''HTTP/2''.

==KTLS==
With Linux kernel 4.13 (3.9.2017) ''Kernel TLS'' was first introduced. In Kernel 4.17 (3.6.2018) ''KTLS'' was completed by adding the so far missing decryption side of things.

It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as [https://www.openssl.org/ OpenSSL]). It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original [https://netdevconf.org/1.2/papers/ktls.pdf paper] by Facebook's Dave Watson reported a '''7%''' reduction in CPU resources.

Netflix Inc., who have done similar changes for [https://www.freebsd.org/ FreeBSD] during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70%. The immediate change for a similar approach as ''KTLS'' only resulted in a 5.88% speed increase. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.737.6630&rep=rep1&type=pdf] Within a year however, they managed to reach a 247.06% speed increase on the baseline OpenSSL traffic, and using highly optimized libraries even managed to increase that percentage to 320.59%. [https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf]