Performance Evaluation of HTTP/2 over TLS+TCP and HTTP/2 over QUIC in a Mobile Network

With the development of technology and the increasing requirement for Internet speed, the web page load time is becoming more and more important in the current society. However, with the increasing scale of data transfer volume, it is hard for the current bandwidth used on the Internet to catch the ideal standard. In OSI protocol stack, the transport layer and application layer provide the ability to determine the package transfer time. The web page load time is determined by the header of the package when the package is launched into the application layer. To improve the performance of the web page by reducing web page load time, HTTP/2 and QUIC has been designed in the industry. We have shown experimentally, that when compared with HTTP/2, QUIC results in lower response time and better network traffic efficiency

HTTP/2: Analysis and measurements

The upgrade of HTTP, the protocol that powers the Internet of the people, was published as RFC on May of 2015. HTTP/2 aims to improve the users experience by solving wellknow problems of HTTP/1.1 and also introducing new features. The main goal of this project is to study HTTP/2 protocol, the support in the software, its deployment and implementation on the Internet and how the network reacts to an upgrade of the existing protocol. To shed some light on this question we build two experiments. We build a crawler to monitor the HTTP/2 adoption across Internet using the Alexa top 1 million websites as sample. We find that 22,653 servers announce support for HTTP/2, but only 10,162 websites are served over it. The support for HTTP/2 Upgrade is minimal, just 16 servers support it and only 10 of them load the content of the websites over HTTP/2 on plain TCP. Motivated by those numbers, we investigate how the new protocol behaves with the middleboxes along the path in the network. We build a platform to evaluate it across 67 different ports for TLS connections, HTTP/2 Upgrade and over plain TCP. Considering both fixed line and mobile network, we use a crowdsourcing platform to recruit users. Middleboxes affect HTTP/2, especially on port 80 for plain TCP connections. HTTP/2 Upgrades requests are affected by proxies, failing to upgrade to the new protocol. Over TLS on port 443 on the other hand, all the connections are successful.Ingeniería Técnica en Sistemas de Telecomunicació

Observing the Evolution of QUIC Implementations

The QUIC protocol combines features that were initially found inside the TCP, TLS and HTTP/2 protocols. The IETF is currently finalising a complete specification of this protocol. More than a dozen of independent implementations have been developed in parallel with these standardisation activities. We propose and implement a QUIC test suite that interacts with public QUIC servers to verify their conformance with key features of the IETF specification. Our measurements, gathered over a semester, provide a unique viewpoint on the evolution of a protocol and of its implementations. They highlight the arrival of new features and some regressions among the different implementations.Comment: 6 pages, 8 figure

Client Certificate and Key Retrieval for IKE

IKE was designed for use with certificates. In a remote access scenario, that implies that clients must possess their own certificates. We leverage off of work already done to fast-start certificate use with IPsec via the Simple Certificate Enrollment Protocol [SCEP]. We use only parts of SCEP over a client authenticated TLS/HTTP connection to a CA. By using TLS, the client can trust a CA root certificate it receives, without an out-of-band verification and the CA can perform automatic enrollment. We replace the out-of-band client identification process for a certificate enrollment with a legacy authentication, like RADIUS. Further, since the certificates issued here are short-lived, there is no need to support client-based revocation or rekeying. Also, there is typically no need for CRL support

Understanding Flaws in the Deployment and Implementation of Web Encryption

In recent years, the web has switched from using the unencrypted HTTP protocol to using encrypted communications. Primarily, this resulted in increasing deployment of TLS to mitigate information leakage over the network. This development has led many web service operators to mistakenly think that migrating from HTTP to HTTPS will magically protect them from information leakage without any additional effort on their end to guar- antee the desired security properties. In reality, despite the fact that there exists enough infrastructure in place and the protocols have been “tested” (by virtue of being in wide, but not ubiquitous, use for many years), deploying HTTPS is a highly challenging task due to the technical complexity of its underlying protocols (i.e., HTTP, TLS) as well as the complexity of the TLS certificate ecosystem and this of popular client applications such as web browsers. For example, we found that many websites still avoid ubiquitous encryption and force only critical functionality and sensitive data access over encrypted connections while allowing more innocuous functionality to be accessed over HTTP. In practice, this approach is prone to flaws that can expose sensitive information or functionality to third parties. Thus, it is crucial for developers to verify the correctness of their deployments and implementations. In this dissertation, in an effort to improve users’ privacy, we highlight semantic flaws in the implementations of both web servers and clients, caused by the improper deployment of web encryption protocols. First, we conduct an in-depth assessment of major websites and explore what functionality and information is exposed to attackers that have hijacked a user’s HTTP cookies. We identify a recurring pattern across websites with partially de- ployed HTTPS, namely, that service personalization inadvertently results in the exposure of private information. The separation of functionality across multiple cookies with different scopes and inter-dependencies further complicates matters, as imprecise access control renders restricted account functionality accessible to non-secure cookies. Our cookie hijacking study reveals a number of severe flaws; for example, attackers can obtain the user’s saved address and visited websites from e.g., Google, Bing, and Yahoo allow attackers to extract the contact list and send emails from the user’s account. To estimate the extent of the threat, we run measurements on a university public wireless network for a period of 30 days and detect over 282K accounts exposing the cookies required for our hijacking attacks. Next, we explore and study security mechanisms purposed to eliminate this problem by enforcing encryption such as HSTS and HTTPS Everywhere. We evaluate each mechanism in terms of its adoption and effectiveness. We find that all mechanisms suffer from implementation flaws or deployment issues and argue that, as long as servers continue to not support ubiquitous encryption across their entire domain, no mechanism can effectively protect users from cookie hijacking and information leakage. Finally, as the security guarantees of TLS (in turn HTTPS), are critically dependent on the correct validation of X.509 server certificates, we study hostname verification, a critical component in the certificate validation process. We develop HVLearn, a novel testing framework to verify the correctness of hostname verification implementations and use HVLearn to analyze a number of popular TLS libraries and applications. To this end, we found 8 unique violations of the RFC specifications. Several of these violations are critical and can render the affected implementations vulnerable to man-in-the-middle attacks

An efficient web authentication mechanism preventing man-in-the-middle attacks in industry 4.0 supply chain

The fourth industrial revolution (Industry 4.0) is transforming the next generation of the supply chain by making it more agile and efficient compared with the traditional supply chain. However, data communication across the partners in the Industry 4.0 supply chain can be the target of a wide spectrum of attackers exploiting security breaches in the internal/external environment of the partners due to its heterogeneous and dynamic nature as well as the fact that the non-professional users in security issues usually operate their information systems. Attackers can compromise the data communication between legitimate parties in the Industry 4.0 Supply Chain, and thus, jeopardizing the delivery of services across the partners as well as the continuity of the service provision. Consequently, secure data communications across the partners in the Industry 4.0 Supply Chain are of utmost importance. Toward this direction, TLS protocol, which is the de facto standard for secure Internet communications, is employed to ensure secure communication between a user's web browser and a remote web server located in the premises of the same or another partner. However, over the last few years, there have been several serious attacks on TLS, including man-in-the-middle attacks in web applications using TLS to secure HTTP communication. Therefore, in this paper, we propose an efficient TLS-based authentication mechanism, which is resistant against MITM in web applications