Quick set up guide for Encrypted Client Hello (ECH)

The Encrypted Client Hello (ECH) mechanism draft-spec is a way to plug a few privacy-holes that remain in the Transport Layer Security (TLS) protocol that’s used as the security layer for the web. OpenSSL is a widely used library that provides an implementation of the TLS protocol. The DEfO project has developed an implementation of ECH for OpenSSL, and proof-of-concept implementations of various clients and servers that use OpenSSL, and other TLS libraries, as a demonstration and for interoperability testing. [Read More]

DEfO - Developing ECH for OpenSSL (round two)

Encrypted ClientHello (ECH) plugs a privacy-hole in TLS, hiding previously visible details from network observers. The most important being the name of the web-site the client wishes to visit (the Server Name Indication or SNI). This can be a major privacy leak, like when accessing a dissident news source hosted on a Content Delivery Network (CDN). A visible domain name also provides a straightforward method for censors to block websites and internet services. [Read More]

Debian over HTTPS

Debian’s package manager apt has a time-tested method of securely providing packages from the network built on OpenPGP signatures. Even though this signing method works well for verifying the indexes and package files, there are new threats that have become relevant as man-in-the-middle attacks and data mining become ever easier. Since 2013, apt developers have supported encrypted transport methods HTTPS and Tor Onion Service. We have been recommending their use since 2013. [Read More]

Implementing TLS Encrypted Client Hello

As part of the DEfO project, we have been working on accelerating the development Encrypted Client Hello (ECH) as standardized by the IETF. ECH is the next step in improving Transport Layer Security (TLS). TLS is one of the basic building blocks of the internet, it is what puts the S in HTTPS. The ECH standard is nearing completion. That is exciting because ECH can encrypt the last plaintext TLS metadata that it is possible to encrypt. [Read More]

NetCipher + Conscrypt for the best possible TLS

A new NetCipher library has recently been merged: netcipher-conscrypt. In the same vein as the other NetCipher libraries, netcipher-conscrypt wraps the Google Conscrypt library, which provides the latest TLS for any app that includes it. netcipher-conscrypt lets apps then disable old TLS versions like TLSv1.0 and TLSv1.1, as well as disable TLS Session Tickets. This is an alpha release because it only works on recent Android versions (8.1 or newer). The actual functionality works well, the hard part remains making sure that it is possible to inject netcipher-conscrypt as the TLS provider on all Android devices and versions. [Read More]

Tweaking HTTPS for Better Security

The HTTPS protocol is based on TLS and SSL, which are standard ways to negotiate encrypted connections. There is a lot of complexity in the protocols and lots of config options, but luckily most of the config options can be ignored since the defaults are fine. But there are some things worth tweaking to ensure that as many connections as possible are using reliable encryption ciphers while providing forward secrecy. A connection with forward secrecy provides protection to past transactions even if the server’s HTTPS private key/certificate is stolen or compromised. [Read More]

VoIP security architecture in brief

Voice over IP (VoIP) has been around for a long time. It’s ubiquitous in homes, data centers and carrier networks. Despite this ubiquity, security is rarely a priority. With the combination of a handful of important standard protocols, it is possible to make untappable end to end encryption for an established VoIP call. TLS is the security protocol between the signaling endpoints of the session. It’s the same technology that exists for SSL web sites; ecommerce, secure webmail, Tor and many others use TLS for security. [Read More]
ostel  ostn  sip  tls  voip  zrtp 

Proposal for Secure Connection Notification on Android

A major problem of mobile applications being increasingly used over web-based applications, is that there is no standard established for notifying the user of the state of security on the network connection. With a web browser, the evolution of the “lock” icon when an HTTPS connection is made, has been one that evolved originally out of Netscape’s first implementation, to an adhoc, defact industry-standard way of letting the user know if their connection is secure. [Read More]