Tony Bemus, Tom Lawrence, Phil Porada and Mary Tomich
Sound bites by Mike Tanner
The LawrenceSystems YouTube Channel Where videos
Microsoft promises to defend—not attack—Linux with its 60,000 patents
Thoughts on Microsoft Joining OIN’s Patent Non-Aggression Pact
We are excited to announce that the KDE e.V. received a donation of 300,000 USD from the Handshake Foundation
Where Vim Came From
Greyhat fixing firewalls, chaotic good?
LibSSH + Cisco = Time to get patching
New WiFi numbering scheme
Bloomberg hardware SuperMicro hacking:Like unicorns jumping over rainbows
The Facebook Hack downgraded to 30 million
Home Audio Overhaul
Raspberry Pi 3b+ with Hifiberry AMP2 connected to speakers
Raspberry Pi 3b+ with an IQaudIO DAC+ feeding to an amplifier which feeds to speakers
Automatic Certificate Management Environment (ACME) Spec
The ACME spec has passed the Internet Engineering Steering Group (IESG)
IETF (Internet Engineering Task Force) has a draft proposal to remove TLS 1.0 and TLS 1.1
This document [if approved] formally deprecates Transport Layer
Security (TLS) versions 1.0 and 1.1 and moves
those documents to a historic state. Those versions lack support
for current and recommended cipher suites.
TLS 1.0 will be 20 years old in January 2019.
Various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008.
Firefox, Chrome, Edge, and Safari are going to be a strong driving force by removing support for TLS 1.0/1.1 and migrating to TLS 1.2 by default.
For webserver operators, I highly recommend checking out https://cipherli.st/
TLS 1.3 has become a proposed standard
=> RFC 8446
How does TLS 1.3 work?
To put it simply, with TLS 1.2, two round-trips have been needed to complete the TLS handshake. With 1.3, it requires only one round-trip, which in turn cuts the encryption latency in half.
Now that TLS.13 is a proposed standard
Encrypted SNI works as follows
The server publishes a public key on a well-known DNS record, which can be fetched by the client before connecting (as it already does for A, AAAA and other records).
The client then replaces the SNI extension in the ClientHello with an “encrypted SNI” extension, which is none other than the original SNI extension, but encrypted with a symmetric key.
To recap: the TLS authentication is done asymmetrically, but internal secure channel is done with a symmetric key for speed.
But then what about the unencrypted DNS?
Security is provided via DNS extensions called DNS over TLS and DNS over HTTPS, but the resolver and authoritative server must support DNSSEC otherwise an attacker would be able to poison the resolver cache.
You can check if your browser supports this feature at https://encryptedsni.com/
The Steam Controller on Ubuntu 18.10 (and other distributions using Linux Kernel 4.18) needs a quick fix
Shutter Removed From Ubuntu 18.10 And Debian Unstable, New PPA Available
Farewell, application menus!
Should GNOME Drop Support for GTK3 Themes?
BSD Wish You Were Secure
This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.