Web PKI: 3 improvements

Written on 24 September 2017, 03:09pm

Tagged with: , ,

Some insights about web security from the excellent ‘Bulletproof SSL and TLS‘ book from Ivan Ristic.

– the Internet was not designed with security in mind
– the first efforts to improve this were in 1995, when SSL3 was released (by Netscape). Then TLS followed up.
– TLS 1.2 – the most recent version – was released in August 2008 (its successor – TLS 1.3 – is still under development, as of September 2017)
– the goal back in 1995 was to enable e-commerce. Today we have that (‘commercial security’), but we want much more.

One of the biggest problem with the Web PKI is the approach to certificate validation. The following improvements aim to fix that:
1. Public Key Pinning:
– addresses the fact that any CA can issue a certificate for any domain name without the owner’s permission.
– with pinning, site owners can select (pin) one or more CAs that they trust, creating their own (small) trust ecosystem
– delivered via HTTP headers (Public-Key-Pins)

2. HTTP Strict Transport Security (HSTS)
– allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
– also, when an invalid certificate is encountered, it instructs compliant browsers to replace warnings with errors, disallowing bypass.
– delivered also via HTTP headers (Strict-Transport-Security)

3. OCSP stapling
– There are two standards for certificate revocation (revocation is used when the private key is compromised or no longer needed)
– CRL (Certificate Revocation List) is a large list of revoked certificate serial numbers maintained by the CA. Because of the size, the lookup is slow
– OCSP (Online Certificate Status Protocol) allows browsers to obtain the revocation status of a single certificate.
– the problem with OCSP is that the individual lookup can slow down browsing and can affect the performance of the OCSP responder for high traffic websites
– to address this, OCSP stapling allows each server to embed an OCSP response directly into the TLS initial handshake

In the end, do not forget that the current Web PKI is controlled by 2 actors: Certificate Authorities (interested in profit) and browser vendors (interested in market share).

Neither group has strong security as its top priority, but they are not necessarily to blame—at least not entirely. They won’t give us security until we, the end users, start to demand it from them.

Update 10 October 2017: I have just enabled HSTS here. Inspired by Troy Hunt.

Random things – session hijacking

Written on 18 March 2017, 11:53am

Tagged with: , ,

Two notes about session hijacking methods:

Difference between stored and reflected XSS attack

Stored or persistent XSS attack – relies on user input stored on the server. Best example – a comment in a news site.
Reflected or non-persistent XSS attack – relies on user input sent in the HTTP query parameters. Best example – site search, showing the keyword after search
Play the XSS game: xss-game.appspot.com

Session fixation

In a nutshell, session fixation means that the attacker obtains a legitimate session ID from the server and then it makes the victim browser to use it. See example.
The counter-measures are quite simple:
– do not accept setting a session id via URL/POST parameters
– change session id after user login
– just use HTTPS and secure cookies, it’s 2017 and HTTPS adoption reached the tipping point

State and the web

Written on 26 February 2017, 06:26pm

Tagged with: , , ,

How do you get around the stateless nature of the web?

The HTTP protocol (along with other building blocks of the web, like IP and HTML) is stateless by design. This means that each connection is made up of a request and response, without any reference to earlier/later connections. “Users don’t log in to the Web, nor do they ever log out”. So without any intervention, each connection to a website (each page visit) is independent from the others.

How do you get around that?
Well, 3 possibilities, all of them using existing elements of the HTTP protocol:
1. HTTP Headers: cookies
2. HTTP URL: query string parameters
3. HTTP Body: POST (form) data
Important to note is that each of these can be altered (spoofed) by the client.

HTTP/2 is still stateless, but has some stateful components

HTTPS is stateless as well. Just because there is a TLS handshake at the beginning does not make the connection stateful. The stateful protocol is TLS, but HTTPS remains stateless, just as HTTP.

Example of a stateful protocol: FTP. “FTP has a stateful control connection which maintains a current working directory and other flags, and each transfer requires a secondary connection through which the data are transferred” (wikipedia)

Summing up:
Stateless: HTTP, HTTPS, IP
Stateful: TCP, TLS, FTP

https://xkcd.com/869/

How to send data from server to client over the web

1: Long polling the client polls the server; the server holds the request open until new data is available. Then the server responds and sends the new information. When the client receives the new information, it immediately sends another request.
2: Server Push – available in HTTP/2: client requests index.html, server responds with index.html but also with style.css and script.js, before the client parses index.html and asks for them
3. WebSockets (ws:// and wss://) – are a HTML5 feature aimed to address the request/response architecture of the web. There is an persistent connection between the client and the server and both parties can start sending data at any time.

Related links:

What really happens when you navigate to a URL
Understanding the concepts of Transport Security Layer (TLS)
How HTTP/2 will speed up your web browsing
XKCD: Server Attention Span
ColdFusion Book
An Introduction to WebSockets

Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the state management mechanism allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a “session”. This context might be used to create, for example, a “shopping cart”, in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user’s previous reading affects which offerings are presented.

Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends.
https://tools.ietf.org/html/rfc2965