Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco Web Security Appliance - HTTP 2.0 Solution Overview

Available Languages

Download Options

  • PDF
    (1.9 MB)
    View with Adobe Reader on a variety of devices
Updated:June 10, 2021

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Available Languages

Download Options

  • PDF
    (1.9 MB)
    View with Adobe Reader on a variety of devices
Updated:June 10, 2021
 

 

The Cisco Web Security Appliance (WSA) intercepts and monitors Internet traffic and applies policies to help keep your internal network secure from malware, sensitive data loss, productivity loss, and other Internet-based threats. Cisco Secure Web Appliance Async OS 14.0 introduces HTTP 2.0 to make applications faster, simpler, and more robust.

HTTP/2

      Reduces latency by enabling full request and response multiplexing

      Minimizes protocol overhead via efficient compression of HTTP header fields

      Supports request prioritization and server push

Why HTTP/2?

HTTP/2 is binary, unlike HTTP/1, which is textual and used to process text commands to complete request-response cycles. HTTP/2 uses binary commands (1s and 0s) to execute the same tasks to ease complications with framing and simplify the implementation of confusingly intermixed commands that contained text and optional spaces.

Multiplexing:

Being fully multiplexed, HTTP/2 can send multiple requests for data in parallel over a single TCP connection to allow the WSA to download web files via ASync mode from one server. Multiplexing allows multiple request and response messages to be in flight simultaneously; it’s even possible to intermingle parts of one message with another on the wire.

HTTP/2 allows the WSA to use just one connection per origin to load a page.

HTTP/1 vs. HTTP/2

HTTP/1 vs. HTTP/2

Additional Benefits

Step 1.       HTTP/2 reduces additional round trip times (RTT), making websites load faster without any optimization.

Step 2.       HTTP/2 Server Push allows the server to send additional cacheable information to the client that wasn’t requested in the anticipation that future requests bring significant performance improvements. For example, if the client requests resource X and understands that resource Y is referenced with the requested file, the server can choose to push both instead of waiting for an appropriate client request.

Server Push 

Figure 2.            

Server Push

Step 3.       HTTP/2 uses header compression to reduce the overhead caused by TCP’s slow-start mechanism and compress many redundant header frames. Both the client and server maintain a list of headers used in previous client-server requests. HPACK compresses each header's individual value before transferring it to the server, which then looks up the encoded information in lists of previously transferred header values to reconstruct the full header information. HPACK header compression for HTTP/2 implementation presents immense performance advantages.

Header Compression

Figure 3.            

Header Compression

4.     HTTP/2 allows for speedier content delivery and improved user experience.

HTTP/2 Response Time

HTTP/2 Response Time

Architectural differences

With HTTP 1.1, the WSA allowed the client-side to open a socket when receiving a request and open another socket on the server-side for communication. The WSA receives a client request, processes it and then sends it to the server and vice versa when it receives a response from the server.

HTTP 1.1 GET

Figure 5.            

HTTP 1.1 GET

HTTP 2.0 enhances this behavior since the WSA allows opening a socket on the client-side when it receives a client's request and opens another socket on the server-side for communication. However, the same set of sockets can handle multiple concurrent HTTP transactions (GET/POST).

Related image, diagram or screenshot

Figure 6.            

HTTP 2.0 GET/POST

Note:     If the client or server doesn’t support HTTP2, the WSA continues to process requests using HTTP1.1. For each HTTP2 request/response, the WSA parses the HTTP2 frame to process it via the WSA policies and configuration.

HTTP/2 Supported features:

1.     Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security extension that allows the application layer to negotiate which protocol to use over a secure connection to avoid additional round trips and is independent of the application-layer protocols. HTTP/2 protocol uses ALPN to decrease website load times further and encrypt connections faster. A TLS handshake is equivalent to two round trips from the client to the server, which adds latency, thus affecting user experience. With ALPN, the client sends a list of supported application protocols to the server as part of the TLS ClientHello message. The server then selects a protocol and returns that protocol in its ServerHello message. Therefore, accomplishing the application protocol negotiation over a single round trip within the TLS handshake allows the server to associate a different certificate with each application protocol.

TLS without/with Application-Layer Protocol Negotiation (ALPN)_A

 

TLS without/with Application-Layer Protocol Negotiation (ALPN)_b

Figure 7.            

TLS without/with Application-Layer Protocol Negotiation (ALPN)

2.     At the core of all the HTTP/2 improvements, the new Binary Framing Layer offers a more compact representation, better process efficiency, and more straightforward implementation. Upon establishing an HTTP/2 connection, the client and server can communicate by exchanging frames, which are the smallest communication unit within the protocol. All frames share a common 9-byte header, making it easier to analyze the byte streams, identify different frame types, determine the active flags, and report each frame's length. Each frame is length-prefixed, so moving from one frame to the next is faster and provides a significant performance improvement over HTTP/1.x.

The HTTP/2 standard defines the following frame types:

      DATA: For transporting HTTP message bodies

      HEADERS: Communicates header fields for a stream

      PRIORITY: Communicates sender-advised priority of a stream. Note: Currently not supported on WSA

      RST_STREAM: Signals stream termination

      SETTINGS: Communicates connection configuration parameters

      PUSH_PROMISE: Signals a promise to a server the referenced resource. Note: Currently not supported on WSA

      PING: Measures the RTT and perform keep-alive

      GO-AWAY: Advises the peer to stop creating streams for the current connection

      WINDOW-UPDATE: Implements flow stream and connection flow control

      CONTINUATION: Continues a sequence of header block fragments

WSA Limitations for HTTP/2 Support:

      No WSA support for:

    Next Protocol Negotiation (NPN) and HTTP2 over TCP (H2C)

    Session cookies and persistent cookies with HTTP2 as in HTTP 1.1 for HTTPS

      ALPN requires a min of TLS1.2 for negotiation between client and server on the WSA

      Only the HTTP 1.0, HTTP1.1 and HTTP 2 from all the available HTTP protocols in ALPN

      Advertising a maximum of 7 protocols in ALPN

      A maximum of 4096 concurrent sessions, with each session supporting up to 128 HTTP streams

      A maximum header size of 16K

      In an explicit setup, the Connect request in HTTP/2 also starts with HTTP1.1

      External DLP, Web Traffic TAP (WTT), Overall bandwidth and Application Bandwidth are not supported when HTTP 2 is enabled. < >

Disabled Features with HTTP 2 Enabled

Disabled Features with HTTP 2 Enabled

Configuring WSA to Start Processing HTTP/2:

1.     HTTP/2 requires WSA Async OS 14.0 or higher.

2.     The http2 CLI command enables or disables HTTP/2 on the WSA. There is no GUI option to enable HTTP2.

Configure WSA for HTTP/2

Figure 9.            

Configure WSA for HTTP/2

3.     You can also choose to restrict any domain functioning incorrectly using HTTP/2 via the WSA and force it to connect on HTTP1.1. Use ADD to add domains to the list. Valid input examples are:

      “www.bbc.com” will restrict all www.bbc.com requests

      “bbc.com” will restrict only “bbc.com” and not “www.bbc.com”

      “.bbc.com” will restrict all subdomains of “bbc.com”

      “.com” restricts all domains ending in “.com”

Restricting Domains

Figure 10.         

Restricting Domains

4.     Use LIST to display the restricted domains/URLs list.

List

Figure 11.         

List

5.     Use DELETE to remove restricted domains/URLs from the list.

Delete

Figure 12.         

Delete

6.     Use FLUSH to remove all the restricted domains/URLs from the list.

Flush

Flush

How does Authentication work with HTTP/2?

AUTHENTICATION with EXPLICIT Proxy deployment:

1.     Authentication happens only once per HTTP/2 Session.

2.     Following an HTTP/2 connection authentication, the following session streams pick up the auth info from the authenticated session and apply policies accordingly.

3.     If surrogates expire while an HTTP/2 session is active and authenticated, reauthentication will not occur.

4.     Access logs show the same username for CONNECT and all subsequent GETS for the same session. The session-id remains the same for all subsequent requests for an HTTP/2 session.

Sample Access Logs of Authentication Info for an Explicit Proxy Deployment

Figure 14.         

Sample Access Logs of Authentication Info for an Explicit Proxy Deployment

5.     The proxy logs for an HTTP2 explicit proxy session have new entries indicating that GET transaction authentication is done for a session and not for individual transactions.

Sample Explicit Proxy log Authentication Entries

Figure 15.         

Sample Explicit Proxy log Authentication Entries

Note:     The highlighted section shows that the User Auth Info was extracted from the Session Authentication for HTTP22 Session.

6.     Session cookies and persistent cookies are not supported with HTTP2 as in HTTP 1.1 for HTTPS.

AUTHENTICATION with TRANSPARENT Proxy deployment:

1.     For HTTP2 transparent proxy deployment, authentication continues to follow the same flow as HTTP1.

2.     The proxy sends additional GOAWAY for HTTP2, 307/Redirect for the HTTP2 connection.

3.     The Session-ID for CONNECT and subsequent GET requests would be different in this transparent proxy deployment.

4.     Authentication Info will be copied over from the Surrogate type for subsequent streams in the same session as in an HTTP1 session.

5.     Access logs show the same username for CONNECT and all subsequent GETS for the same session. The session-id differs for an initial CONNECT and the subsequent GET requests because a transparent proxy deployment terminates the initial HTTP2 session after a 307 Redirect.

Sample Transparent Proxy Deployment Access Logs showing Authentication Info.

Figure 16.         

Sample Transparent Proxy Deployment Access Logs showing Authentication Info.

6.     The proxy logs for a WSA deployed in Transparent mode for an HTTP2 session have new entries showing the GET transactions authentication using the authentication information in the surrogate cache for the second HTTP/2 TCP_CONNECT request as in HTTP1. Having authenticated the TCP_CONNECT, the subsequent streams will use session auth to do the authentication.

Sample transparent proxy authentication log entries:

Sample transparent proxy authentication log entries:

Log Subscription Changes

Log subscription changes help to troubleshoot HTTP/2 connection requests.

S.No

Format Specifier in Access Logs

Log Field in W3C Logs

Description

Examples

1.

%X#31#

x-alpn-protocol-negotiation

To check what all protocols advertised by client and negotiated by server during ALPN

x-alpn-protocol-negotiation= <"h2"-"h2"-"h2"-"h2">

Note: When Client has sent only h2 in ALPN

2.

%X#32#

x-h2-session-id

Used to uniquely identify streams/requests processed for a particular H2 Session.

x-h2-session-id= 241

Note: When Session Id of H2 Session is 241

3.

%X#33#

x-h2-client-settings

Logs the exchanged C2P setting parameters of H2 SESSION in H2SESSION access logs.

x-h2-client-settings= {[HEADER_TABLE_SIZE] = 4096 [ENABLE_PUSH] = 0 [MAX_CONCURRENT_STREAMS] = 100 [INITIAL_WINDOW_SIZE] = 65535 [MAX_FRAME_SIZE] = 16384 [MAX_HEADER_LIST_SIZE] = 65536

4.

%X#34#

x-h2-server-settings

Logs the exchanged S2P setting parameters of H2 SESSION in H2SESSION access logs.

x-h2-server-settings= {[MAX_CONCURRENT_STREAMS] = 100}

5.

%X#35#

x-stream-id

To identify client-side and server-side stream mapping of a particular stream/request

For GET/streams: x-stream-id= (1, 1) Note: In CONNECT and H2SESSION it will be (0, 0)

6.

%X#36#

x-c2p-bytes

To check total decrypted H2 bytes received from client for a stream and summation of all Streams in H2SESSION

H2: x-c2p-bytes= 108 HTTP1.1: x-c2p-bytes= 0

7.

%X#37#

x-p2c-bytes

To check total decrypted H2 bytes sent to client for a stream and summation of all Streams in H2SESSION

Note:- Not applicable for HTTP1.1, it will be 0

H2: x-p2c-bytes= 40993 HTTP1.1: x-p2c-bytes= 0

8.

%X#38#

x-s2p-bytes

To check total decrypted H2 bytes received from server for a stream and summation of all Streams in H2SESSION

Note:- Not applicable for HTTP1.1, it will be 0

H2: x-s2p-bytes= 40946 HTTP1.1: x-s2p-bytes= 0

9.

%X#39#

x-p2s-bytes

To check total decrypted H2 bytes sent to server for a stream and summation of all Streams in H2SESSION

Note:- Not applicable for HTTP1.1, it will be 0

H2: x-p2s-bytes= 179 HTTP1.1: x-p2s-bytes= 0

10.

%X#40#

x-debug

Debug and statistics of a particular HTTP2 session.

Note: It was for developer use, format may change).

x-debug= (strm:2,strmErr:0)(cr:2,cw:112,crr:0,sr:63,sw:19,t:5,fgt:4)c2p(s:2,sa:1.d:0,db:0,h:2,hb:69,rst:0,wu:1,gw:0,p:2)p2c(s:1,sa:2,d:6,db:77410,h:2,hb:396,rst:0,wu:1,gw:0;p:2)p2c(s:1,sa:2,d:6,db:77410,h:2,hb:396,rst:0,wu:1,gw:1,p:1)p2s(s:2,sa:1,d:0,db:0,h:2,hb:117,rst:0,wu:5,gw:1,p:2)s2p(s:1,sa:2,d:6,db:77410,h:2,hb:362,rst:0,wu:1,gw:0,p:1)

 

Sample Access Logs

Figure 18.         

Sample Access Logs

Sample W3C Logs

Figure 19.         

Sample W3C Logs

HTTP Module Introduced in Proxy Logs showcases an HTTP/2 Transaction

Figure 20.         

HTTP Module Introduced in Proxy Logs showcases an HTTP/2 Transaction

Conclusion

By supporting HTTP2.0, the Secure Web Appliance has taken a big step towards providing efficiency, security and speed. Enjoy reduced web request latency due to faster handshakes and make the most of available resources at the same time. HTTP/2 is a more robust protocol giving us increased page load speeds and security. It uses a single TCP connection and keeps it warm enough for concurrent downloads. Slow websites kill the user experience.

 

 

 

Learn more