Explore the vast range of titles available.

Network steganography has existed for several decades and it uses network traffic and network protocols as carriers for embedding secret messages in a stealthy manner. Quick UDP Internet Connections (QUIC) is a novel secure and reliable transport layer network protocol that is encapsulated in the User Datagram Protocol (UDP) and utilizes the Transport Layer Security Version 1.3 (TLSv1.3) standard. In addition, Hypertext Transfer Protocol Version 3 (HTTP/3) employs QUIC. In this paper, we present a systematic analysis of the covert channels that can be found in QUIC. Twenty novel covert channels are identified by applying the latest covert channel pattern based taxonomy, and an analysis of their transmission rate, undetectability, and robustness is presented, together with suggested countermeasures. A single covert channel is implemented as a proof of concept tool and is appropriately evaluated.

Built on top of UDP, the recently standardized QUIC protocol primarily aims to gradually replace the TCP plus TLS plus HTTP/2 model. For instance, HTTP/3 is designed to exploit QUIC’s features, including reduced connection establishment time, multiplexing without head of line blocking, always-encrypted end-to-end security, and others. This work serves two key objectives. Initially, it offers the first to our knowledge full-fledged review on QUIC security as seen through the lens of the relevant literature so far. Second and more importantly, through extensive fuzz testing, we conduct a hands-on security evaluation against the six most popular QUIC-enabled production-grade servers. This assessment identified several effective and practical zero-day vulnerabilities, which, if exploited, can quickly overwhelm the server resources. This finding is a clear indication that the fragmented production-level implementations of this contemporary protocol are not yet mature enough. Overall, the work at hand provides the first wholemeal appraisal of QUIC security from both a literature review and empirical standpoint, and it is therefore foreseen to serve as a reference for future research in this timely area.

The HTTP Alternative Services (Alt-Svc) method is defined as an application to check connectivity in HTTP/3. This method is designed based on the fact that communication with old HTTP is guaranteed and the HTTP/3 adoption rate is not necessarily dominant, and it is considered effective in the early stages of transition. However, once HTTP/3 has reached its peak and the transitional period has passed, the uncertainty and redundancy of the Alt-Svc procedure become detrimental. In Alt-Svc, the procedure involves first completing the old HTTP connection to use HTTP/3, and then migrating to HTTP/3 if possible; however, because HTTP/3 is a protocol that eliminates the waste of the old HTTP handshake (TCP handshake followed by TLS handshake), HTTP/3 does not fully benefit from the rapid connection establishment of HTTP/3. Therefore, we propose a method to apply the Happy Eyeballs algorithm, which is used for IPv4 and IPv6 connectivity checks, to the old HTTP and HTTP/3 connectivity checks. The Happy Eyeballs algorithm performs the two selections in parallel to eliminate the delay that occurs in sequential processing, but the proposed method differs from the conventional Happy Eyeballs algorithm in that, even if the old HTTP is adopted once, it switches to the HTTP/3 connection if it is possible to connect using HTTP/3. The proposed method differs from the conventional Happy Eyeballs algorithm by introducing a mechanism to switch to HTTP/3 connections when HTTP/3 connections are available, even when the old HTTP is adopted. Results of the evaluation experiments demonstrated that the adoption rate of HTTP/3 increases in environments with high communication latency because the old HTTP performs the TLS handshake after the TCP handshake, but with this improvement, HTTP/3 is preferentially selected even in low latency environments when it is selectable.

The rapid development of the digital healthcare and the electronic health records (EHR) requires smooth networking infrastructure to access data using Hypertext Transfer Protocol (HTTP)-based applications. The new HTTP/3 standard should provide performance and security improvements over HTTP/2. The goal of our work was to test the performance of HTTP/2 and HTTP/3 in the context of the EHRs. We used 45,000 test FHIR Patient resources downloaded and uploaded using 20, 50, 100 and 200 resources per Bundle, which resulted in 2251, 901, 451 and 226 HTTP GET and POST requests respectively. The first test downloading 20 resources per Bundle showed that HTTP/3 outperformed HTTP/2 in the local (mean request time 16.57 ms ± 7.2 standard deviation [SD]) and in the remote network (71.45 ms ± 43.5 SD) which is almost 3 times faster. In the 50 and 100 resources per Bundle test the HTTP/3 protocol demonstrated again more than two times gain in downloading performance for remote requests with mean request time 91.13 ms ± 34.54 SD and 88.09 ms ± 21.66 SD respectively. Furthermore, HTTP/3 outperformed HTTP/2 in the constructed clinical dataset remote transfer. In the upload tests HTTP/3 showed only a slight gain in performance merely in the remote network. The HTTP/3 protocol is a relatively new development and a major improvement for the worldwide web. This new technology is still missing in the digital health and EHRs. Its use could offer a major performance gain in situations where data is gathered from multiple remote locations.

New versions of HTTP protocols have been developed to overcome many of the limitations of the original HTTP/1.1 protocol and its underlying transport mechanism over TCP. In this paper, we investigated the performance of modern Internet protocols such as HTTP/2 over TCP and HTTP/3 over QUIC in high-latency satellite links. The goal was to uncover the interaction of the new features of HTTP such as parallel streams and optimized security handshake with modern congestion control algorithms such as CUBIC and BBR over high-latency links. An experimental satellite network emulation testbed was developed for the evaluation. The study analyzed several user-level web performance metrics such as average page load time, First Contentful Paint and Largest Contentful Paint. The results indicate an overhead problem with HTTP/3 that becomes more significant when using a loss-based congestion control algorithm such as CUBIC which is widely used on the Internet. Also, the results highlight the significance of the web page structure and how objects are distributed in it. Among the various Internet protocols evaluated, the results show that HTTP/3 over QUIC will perform better by an average of 35% than HTTP/2 over TCP in satellites links specifically with a more aggressive congestion algorithm such as BBR. This can be attributed to the non-blocking stream multiplexing feature of QUIC and the reduced TLS handshake of HTTP/3.

The paper investigates the performance properties of the new HTTP/3 protocol in IoT scenarios, with the focus on fog computing. A specific experimental environment is created, providing realistic IoT conditions. End-to-end delay and three different models for packet loss are introduced using the NetEm simulator in Linux. Three contemporary HTTP protocols are contrasted with two scenarios of IoT use. By comparing the experimental results obtained by the protocols HTTP/1, HTTP/2 and HTTP/3, it can be noticed that the protocol HTTP/3 outperforms the protocol HTTP/2 in 19 cases out of 24, yet it only outperforms HTTP/1 in 12 cases out of 24. Even if HTTP/3 is under development, it fulfils the requirements for performance and security for IoT and fog computing scenarios, involving unconstrained devices. With a lower connection overhead and an inherent security, HTTP/3 has secured a firm place for itself among other specialised IoT protocols.

With the introduction of HTTP/3, whose transport is no longer the traditional TCP protocol but the novel QUIC protocol, research for solutions to the unfairness of Adaptive Streaming over HTTP (HAS) has become more challenging. In other words, because of different transport layers, the HTTP/3 may not be available for some networks and the clients have to use HTTP/2 for their HAS applications instead. Therefore, the scenario in which HAS over HTTP/3 (HAS/3) competes against HTTP/2 (HAS/2) must be considered seriously. However, there has been a shortage of investigations on the performance and the origin of the unfairness in such a cross-protocol scenario in order to produce proper solutions. Therefore, this paper provides a performance evaluation and root-cause analysis of the cross-protocol unfairness between HAS/3 and HAS/2. It is concluded that, due to differences in the congestion control mechanisms of QUIC and TCP, HAS/3 clients obtain larger congestion windows, thus requesting higher video bitrates than HAS/2. As the problem lies in the transport layer, existing client-side ABR-based solutions for the unfairness from the application layer may perform suboptimally for the cross-protocol case.

Dynamic Adaptive Streaming over HTTP (DASH) is a widely used standard for video content delivery. Video traffic, most of which is generated from mobile devices, is shortly to become the most significant part of Internet traffic. Current DASH solutions only consider either client- or server-side optimization, leaving other components in DASH (e.g., at the transport layer) to default solutions that cause a performance bottleneck. In that regard, although it is assumed that HTTP must be necessarily transported on top of TCP, with the latest introduction of HTTP/3, it is time to re-evaluate its effects on DASH. The most substantial change in HTTP/3 is having Quick UDP Internet Connections (QUIC) as its primary underlying transport protocol. However, little is still know about the effects on standard DASH client-based adaption algorithms when exposed to the future HTTP/3. In this paper, we present SAND/3, an SDN (Software Defined Networking)-based Quality of Experience (QoE) control method for DASH over HTTP/3. Since the official deployment of HTTP/3 has not been released yet, we used the current implementation of Google QUIC. Preliminary results show that, by applying SAND/3, which combines information from different layers orchestrated by SDN to select the best QoE, we can obtain steadier media throughput, reduce the number of quality shifts in at least 40%, increase the amount downloaded content at least 20%, and minimize video interruptions compared to the current implementations regardless of the client adaption algorithm.