Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

24

Firefox and Chrome start warning about insecure login forms

31 January 2017

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.

Firefox and Chrome start warning about insecure login forms

Two major browser vendors have started to warn about forms which are transmitted over insecure connections and intended to transmit sensitive data. If a web page that is transmitted via unprotected HTTP contains a form with a password field, then the latest Firefox version 51 will show a lock with a red stroke and Chrome 56 will display “Not secure” in front of the URL.

This tackles a situation that is relatively common which happens because of misunderstanding of HTTPS. If a form is transmitted via HTTP and the data from the form is sent through HTTPS, then usually the data is transmitted securely. However, an attacker can manipulate the form and force the data to be sent to a location he or she controls. Such attacks are known as SSL Stripping.

Quite a few notable sites have been caught by this issue, for example the German ISP Vodafone, the free software code hosting site Savannah (which the author of this Newsletter pointed out a while ago), the airline Quantas and many more.

Illegit certificates from GoDaddy, Symantec and more

Two major incidents where certificate authorities issued illegit certificates were made public this month.

GoDaddy announced that 8850 certificates were issued without proper validation of the domain owner. This was due to a bug that got introduced in June 2016 and was discovered in early January 2017.

Andrew Ayer discovered via the Certificate Transparency logs that Symantec had apparently issued several test certificates for domains whose owners hadn’t requested them. The certificates were issued for domains like example.com, test.com and similar domains. Symantec explained that these certificates were issued by a partner - the Korean Electronic Certification Authority. Symantec had already had an incident in 2015, where they issued unauthorized test certificates for several domains, including google.com.

Following this incident, further similar test certificates issued by GlobalSign and Verizon were discovered.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Short News

  • GnuTLS has fixed two memory corruption vulnerabilities in the parsing of certificates. These had been discovered by Google’s OSS-FUZZ project.
  • OpenSSL has fixed four security vulnerabilities. These include an out of bounds read, a client crash on bad key exchange parameters, and two carry propagation bugs in the bignum functions.
  • Kaspersky’s Antivirus software is using TLS man-in-the-middle interception in order to read encrypted connections. Tavis Ormandy from Google’s Project Zero has found a major vulnerability: due to a bug, the RSA key size is effectively reduced to 32 bit. This comes at a time where antivirus software is heavily criticized by many security experts.
  • The New York Times, Bloomberg, Ars Technica and QZ have recently enabled HTTPS by default.
  • A research paper proposes a new code-based post-quantum encryption scheme: Efficient Encryption from Random Quasi-Cyclic Codes. Older code-based encryption schemes are considered very secure, but impractical due to their large keys. Therefore there are attempts to create more efficient code-based encryption schemes.
  • The US government’s 18F, which is responsible for the transition of government web pages to HTTPS, published the tool pshtt. It can be used to discover the status of HTTPS and certain features in a machine readable JSON output.
  • Curl developer Daniel Stenberg wrote a blog post explaining that non-browser HTTPS clients usually have a lower level of HTTPS security.
  • Chrome plans to remove the notifications API for insecure HTTP pages.
  • SourceForge enabled HTTPS checkout options for Subversion and Git repositories.
  • Johannes Weber discusses whether the deployment of DANE/TLSA would cause issues with TLS interception devices. Both DANE and TLS interception are highly controversial and it currently doesn’t look like DANE will be supported by browsers any time soon.
  • Scott Arciszewski presents a plan to make libsodium-based cryptography available in PHP. PHP currently has limited support for strong, modern cryptographic algorithms.
  • Google developer Emily Stark presents Expect-CT, an HTTP header which a site can use to indicate the support of Certificate Transparency, similar to HSTS and HPKP.
  • Viktor Dukhovni collected statistics about the deployment of DANE TLSA records for SMTP.
  • Diogo Mónica explains how to do hitless certificate rotation in Go applications.
  • Chrome plans to implement Token Binding, which can be used to bind Cookies to the TLS layer and avoid Cookie stealing in certain scenarios.
  • A severe vulnerability made an AES implementation for Ruby practically useless. While the affected Ruby gem wasn’t widely used, it shows up as the first result if someone googles for an AES Ruby gem.
  • Tobias Ospelt writes about a race condition that could cause the iOS Twitter app to connect to a server with a wrong certificate. It was fixed by Twitter, but it is probably related to an underlying problem in iOS.
  • The next conference on Post-Quantum Cryptography (PQCrypto) will be held in Utrecht in June.
  • Eric Lawrence reports about Let’s Encrypt certificates that contain variations of the name PayPal and are used for phishing web pages. Let’s Encrypt wrote a statement about the abuse of certificates for phishing in 2015. While they check the Google Safebrowsing API for malicious domains and don’t issue certificates for them, Let’s Encrypt and many others hold the position that it’s not the job of a certificate authority to police content and certificates can always be issued to someone controlling a domain independent of its purpose.
  • Mozilla developer Panos Astithas explains various security features in Firefox. Regarding TLS he notes that the most common cause for certificate failures in the browser are wrong clocks on clients.
  • DOIs, which are identifiers for scientific publications, should be linked via HTTPS in the future.
  • New subdomains from the US government under the dot gov top level domain will have to support HTTPS and HSTS.
  • OpenSSL announced that its TLS 1.3 implementation will be sponsored by Akamai and a version supporting it should be published in April.
  • Representatives from several browsers, large web pages, CDN networks and the HTTPS Everywhere plugin met to discuss the future of HSTS and the HSTS preloading list. The minutes of the meeting are available to the public.
  • Joel Sing presented the libtls API from LibreSSL at the linux.conf.au.
  • In a livestream to AdWords customers Google explained the importance of HTTPS to AdWords customers. The recording of the livestream is available.
  • Google announced that it is creating its own certificate authority. Google already had a valid intermediate certificate in the past and was able to issue its own certificates. Now they’ve bought two root certificates and want to push their own certificates into applications.
  • Project Everest is a research project that tries to implement a verified TLS stack. Many of the participating researchers from INRIA Paris and Microsoft research have discovered notable vulnerabilities in the TLS protocol and in implementations.
  • Facebook is developing Zero, an encrypted transport protocol similar to Google’s QUIC.
  • Chrome will deprecate the matching of the CommonName field in certificates. Certificates can contain hostnames in two forms: as the CommonName and as the SubjectAltName. The CommonName can only contain one hostname. For a while it has been common that certificate authorities always add the CommonName also to the SubjectAltName field, thus this change should not affect valid certificates.
  • VPNs can be a security risk: in a recent test 18 percent of Android VPN applications didn’t encrypt the traffic and 38 percent showed signs of malware.
  • Videos from the talks at the Real World Crypto conference are available.
  • A workshop on High Assurance Crypto Software (HACS) happened directly after Real World Crypto, as Tim Taubert from Mozilla reports.
  • The immigration ban of the new US government also affects cryptography students who can’t continue their PhD in the US. Cryptographer Kenny Paterson started a list of researchers outside the US who offer to help students to continue their studies at other places.
  • Oracle announced that it will soon no longer accept MD5 signatures for JAR files. MD5 has been known to be weak since 1996 and is considered broken since 2004.
  • Researchers have investigated various security products that use so-called TLS interception and utilize man-in-the-middle attacks to read TLS encrypted traffic. They come to the conclusion that “nearly all reduce connection security and many introduce severe vulnerabilities”.

Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.

Remote and trainer-led, with small classes and a choice of timezones.

Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More

@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Newsletter
  • SSL/TLS and PKI History
  • Archived Books
  • Bulletproof TLS Guide

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us