Category: TLS

Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017


Want to learn the latest about DNS privacy? About the latest research and techniques to protect the confidentiality of your DNS info and queries?

Starting at 8:55 am PST (UTC-8) today, there will be what looks to be an outstanding workshop on DNS Privacy streaming live out of the Network and Distributed System Security Symposium (NDSS) in San Diego, California.

View the agenda of the DNS Privacy Workshop to see all the excellent sessions.  You can then join live at:

(Other remote connection options can be found at the bottom of the agenda page.)

Note – this workshop is not about DNSSEC, which is a method to protect the integrity of DNS (to ensure DNS info is not modified in transit), but rather new work being done within the IETF to improve the confidentiality of DNS.

The sessions include:

  • How DNS Works in Tor & Its Anonymity Implications
  • DNS Privacy through Mixnets and Micropayments
  • Towards Secure Name Resolution on the Internet – GNS
  • Changing DNS Usage Profiles for Increased Privacy Protection
  • DNS-DNS: DNS-based De-NAT Scheme
  • Can NSEC5 be practical for DNSSEC deployments?
  • Privacy analysis of the DNS-based protocol for obtaining inclusion proof
  • Panel Discussion: The Tension between DNS Privacy and DNS Service Management
  • The Usability Challenge for DNS Privacy and End Users
  • An Empirical Comparison of DNS Padding Schemes
  • DNS Service Discovery Privacy
  • Trustworthy DNS Privacy Services
  • EIL: Dealing with the Privacy Problem of ECS
  • Panel Discussion: DNS-over-TLS Service Provision Challenges: Testing, Verification,

If you are not there in person (as I will not be), you can also follow along on the #NDSS17 hashtag on Twitter. There will also be tweets coming out of:

Stéphane Bortzmeyer will also be attending (and speaking at) the workshop – and he is usually a prolific tweeter at @bortzmeyer.

The sessions will also be recorded for later viewing. I’m looking forward to seeing the activity coming out of this event spur further activity on making DNS even more secure and private.

Please do follow along remotely – and please do share this information with other people you think might be interested. Thank you!

Image from Unsplash – I thought about showing the wide beaches, but the reality is that the conference participants won’t really get a chance to visit them. I thought “Lifeguard” was appropriate, though, because lifeguards are all about protecting people and keeping things safe.

Join InterCommunity 2015 on July 7/8 to talk about Internet security!

InterCommunity 2015 logoThis week you have a unique opportunity to offer your opinion on how we can make the Internet more secure!  On July 7 and 8 our global Internet Society membership meeting, InterCommunity 2015, will bring together thousands of people all around the world to address critical questions around the future of the Internet – how it is governed, how it is secured and how we bring the rest of the world online.  YOU CAN JOIN IN DIRECTLY by going to this site to register:

You can join in from your computer or mobile device in your home, at your office or wherever you can get connectivity.

This is a global meeting happening ON the Internet – and FOR the Internet!

In some cities across the world we will have “regional nodes” where people will be gathering together in a location to join into conversations with each other – and then to join into the global conversation.  You are welcome to gather in one of those locations… or to join in from wherever you are.  There are opportunities to connect in and have your voice heard from wherever you can connect.

As you can see on the InterCommunity agenda, the meeting will be running twice to bring in everyone around the world and will have different people and different segments.  The goal is to bring all our members together, to exchange views and to come together to use our collective strength to address these critical issues and bring about a stronger and more secure Internet.

Please READ THIS POST from Internet Society President and CEO Kathy Brown for more information!

I’ll actually be in Ottawa, Ontario, Canada, at the regional node there where I’ll be leading part of the global conversation about collaborative security and how we can all work together to make the Internet more secure.  If you are there in Ottawa, I look forward to meeting you face-to-face.  If you are online, I look forward to interacting with you.  The topics we cover here on Deploy360 are all about making the Internet more secure and accessible… all key themes here in InterCommunity 2015!

Please join with us!  It’s gonna be great!

P.S. What?  You aren’t a member of the Internet Society?  No worries… it’s free to join and become a member!

New RFC 7469 on Certificate Pinning – HTTP Public Key Pinning (HPKP)

TLS badgeA couple of weeks ago those of us interested in Internet security formally received a new tool in our toolbox to improve the overall security of the TLS infrastructure that we use for pretty much all secure communication across the Internet. RFC 7469, “Public Key Pinning Extension for HTTP” was published and is available at:

I say “formally” because in practice what is more commonly known as “HPKP” or “PKP” has been implemented for some time now by Google Chrome and Mozilla Firefox (see ticket) as the Internet-Draft worked its way through the WEBSEC Working Group within the IETF on its way to becoming a formal RFC.

At a basic level, “certificate pinning” is a fairly simple concept: once you connect to a site and receive its TLS certificate (i.e. you switch to using HTTPS and have the “lock” icon in your browser), “pin” that certificate inside your application for a specified period of time and ONLY accept connections that use that exact TLS certificate.  This removes the possibility of an attacker succeeding with a Man-In-The-Middle (MITM) attack where the attacker can fool your browser into thinking you are connecting to the correct secure site.  (If you want a deeper dive, OWASP has a long description of certificate pinning.)

Certificate pinning is a concept that has been around for a while but this new HPKP header makes it easier for sites to implement.

RFC 7469’s abstract doesn’t put it quite so simply as I did above, but you get the idea:

This document defines a new HTTP header that allows web host operators to instruct user agents to remember (“pin”) the hosts’ cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.

Now in practice it turns out that pinning the exact TLS certificate can cause operational problems in some website configurations and so the specification allows for the pinning of the key of the entity that issues the TLS certificates for your site, such as a certificate authority (CA).  This allows you, for instance, to specify that a browser should only accept TLS certificates from a specific CA.  This reduces the risk of a MITM attack where an attacker uses a TLS cert from a different CA who they were able to get to issue the bogus cert.

This new RFC 7469 dives into all the details of HPKP, but if you want a higher level view, Joseph Bonneau gave a talk in March 2015 at IETF 92 in Dallas about HPKP and its companion, HTTP Strict Transport Security (HSTS – RFC 6797). The slides are available:

cert-pinning-saag-ietf92and you can listen to the presentation starting at about 24:30 in the recording of the SAAG session.

Certificate pinning is a great tool that we have now, although it does have a few challenges to be aware of:

  • Trust-On-First-Use (TOFU) – Certificate pinning relies on you connecting to the correct server on the first connection in order to get the TLS cert that you are now going to pin in the browser.   As noted in the RFC 7469 Introduction, the issue is that if you were to connect to an attacker’s site first you could in fact wind up pinning the false certificate and thereby being blocked out of connecting to the correct site until the time of the pin expires (what is called in the spec “max-age”).
  • Blocking a site due to certificate changes  – If you need to change a TLS cert, or if a TLS cert should be compromised or a private key is lost, you could potentially wind up in a situation where people using browsers that perform cert pinning would not be able to get to your site.  This could happen if you pinned to an exact cert and had to change the cert, or if you pinned to a CA and then switched to a new CA, and in either case were unable to provide enough notice to manage the migration. The Security Considerations section of RFC 7469 discusses this issue.

On the TOFU issue, one way to deal with having to trust the site on first use is to “pre-load” the certificate to be pinned into the web browser or other application.  This is being done by both Chrome and Firefox (see Mozilla’s list).  The only concern here is that if you need to change the certificate in the pre-loaded list, you need to wait for an update to the browser to be available (and for users to install that update).

In various conversations I’ve suggested DNSSEC could help here because if the local system performed DNSSEC validation on a signed domain, the browser would then have a high level of assurance that it was connecting to the correct IP address where it could then receive a HPKP header with the correct TLS cert to be pinned.  So DNSSEC could help bootstrap the pinning process and get around the TOFU concern.

Whenever I’ve raised this point, the response has typically been that if you have DNSSEC validation available you could simply use DANE to ensure you are using the correct TLS certificate.  This is true, and I’d like to hope we’ll someday get there, but: 1) DANE requires the creation and usage of TLSA records, which is one more step people have to take; and 2) web browsers don’t have full support of DANE yet (although plugins are available).  In the meantime, I still see DNSSEC as a powerful way to help with ensuring cert pinning works correctly.

Regardless, the key point is that RFC 7469 is now out there and certificate pinning via the HPKP header is now possible.  It’s another tool we have and one that anyone interested in TLS security should definitely understand.

I’d love to hear your comments on this – please do feel free to leave them here.  Tell me why cert pinning is great… tell me why it’s not.  Tell me I’m wrong (or right!).  Please do note that we do moderate comments because of spam but we approve basically very comment that isn’t abusive or spam. Provides An Easy Way To Test Your IPv6, DNSSEC and TLS

“Is Your Internet Up-To-Date?” Does your existing Internet connection work with IPv6 and DNSSEC? Do your web sites support IPv6, DNSSEC and TLS?  Is there a quick way to find out?

Earlier this month a new site,, was launched to make this all easy for anyone to test.  All you do is visit the site at (also available in Dutch) and just follow the very easy links: web siteAll you do is click “Test my internet connection” to find out if your current connection supports IPv6 and DNSSEC.  Enter any website address to test whether that site supports IPv6, DNSSEC and TLS.  And enter any email address to find out if it supports IPv6, DNSSEC and DKIM/SPF/DMARC.

Here was the response I received for one of my email accounts: email test

You then have a link you can follow to get more details.

While there are obviously more detailed tests that can be performed, this site does a nice job giving a high level view of whether your connections are protected.  I also like the fact that it uses “regular” language to explain why someone should care about these tests, rather than using the technical acronyms.

The site is great to have out there and we’ll be adding it to our list of DNSSEC tools and other places within Deploy360.

Congratulations to the various organizations behind on the launch!  May this new site help many more people learn what they need to do to bring their Internet connections and sites up-to-date!

P.S. Please also read Olaf Kolkman’s post providing another perspective on the launch. And yes, both the Internet Society and our Internet Society Netherlands Chapter were involved with the launch.  If you would like to get started with IPv6, DNSSEC or TLS, please visit our Start Here page to begin!



Deploy360@IETF92, Day 4: More IPv6 Operations, TLS, and much Security

IETF 92 - Kathleen MoriartyThis  fourth day of IETF 92 has a heavy focus on security for us on the Deploy360 team.  While the day starts with the second of two IPv6 Operations (v6OPS) working group sessions, the rest of the day is pretty much all about security, security, security!

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, the second IPv6 Operations (v6OPS) sessions continues with their busy agenda in the Gold Room. Here are today’s topics:

A number of those should generate good discussion.

Meanwhile, over in the Oak Room, the TLS Working Group will be discussing improvements to this incredibly critical protocol that we are using to encrypt so many different communications over the Internet.  As my colleague Karen O’Donahue wrote:

The tls (Transport Layer Security) working group is actively working on an update to the TLS protocol. They recently conducted an interim meeting in Seattle, WA, on 10-11 March 2015. Agenda items for IETF 92 include backwards compatibility, rekeying, and client authentication.

After lunch the 1300-1500 CDT block has the Security Area Open Meeting in the International Room. The current agenda is this:

  • Joe Bonneau/HSTS and HPKP in practice (30 mins)
  • Adam Langley/QUIC (15 mins)
  • Jan Včelák/NSEC5 (10 mins)
  • Ladar Levinson/Darkmail (20 mins)
  • Paul Wouters/Opportunistic IPsec update (1 minute)
  • Eric Rescorla/Secure Conferencing (5 mins)

Several of these presentations tie directly into the work we are doing here.  The HSTS/HPKP is “certificate pinning” and very relevant to TLS, as is the QUIC presentation.  The NSEC5 is a new proposal for DNSSEC that, judging by the mailing list traffic, should get strong debate.

The 1520-1720 CDT block doesn’t contain any of the working groups we usually track, but there will be both a Routing Area Open Meeting as well as an Operations Area Open Meeting.

In the final 1740-1840 CDT block the Operational Security (OPSec) Working Group will be meeting in the Far East Room with a number of IPv6 and routing issues on their agenda.


The day will end with the Bits-and-Bites reception from 1900-2100 CDT  where attendees can get food and drink and also see various exhibits from sponsors and other organizations.  As I wrote in my Rough Guide post:

 I’m told that one table will be from Verisign Labs where they will be showing demonstrations of the getdns API being used with DNSSEC and DANE.  I’m not exactly sure what will be there, but if you are going to Bits-and-Bites you may want to stop by their table and see what it is about.

I understand there may be some cool demos from other vendors and groups as well. (I’m looking forward to seeing photos!)

For some more background, please read these Rough Guide posts from Andrei, Phil and Karen:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo from Jari Arkko of Kathleen Moriarty and Lisandro Granville at the IETF 92 Administrative Plenary

Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW)

Jen Linkova at IETF 92Today’s third day of IETF 92 turns out to be a quieter one for the topics we cover here on Deploy360.  The big activity will be in the first of two IPv6 Operations (v6OPS) working group sessions.  There will also be a reboot of the SUNSET4 working group and what should be an interesting discussion about “route leaks” in the GROW working group.  Here’s what our day looks like…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, we’re not actively tracking any of the listed working groups as they don’t tie directly into our Deploy360 topics. However the BESS session about BGP-enabled services could be interesting, as could the SPUD BOF looking at what are barriers to implementing new transport protocols on the Internet (more info in the SPUD overview presentation).

After lunch from 1300-1500 CDT in the International Room will be the first of two IPv6 Operations (v6OPS) sessions (the second being tomorrow) with a packed agenda looking at design choices for IPv6 networks, IPv6 deployment case studies / lessons learned and more.  As IPv6 deployment continues to grow month over month, incorporating feedback from that deployment process back into the standards process is an essential part of ensuring continued growth.

In the 1520-1620 CDT block over in the Gold Room, the IPv6 discussion will continue in the SUNSET4 working group that is chartered to document and explore how well things will work in an IPv6-only environment when IPv4 is no longer available (i.e. IPv4 has “sunsetted”).  As noted in the SUNSET4 agenda, the working group has had a loss of momentum and will be looking today at how to restart efforts to move work items along.

Simultaneously over in the Parisian Room the Global Routing Operations (GROW) working group will be looking at how to improve the operations of the Internet’s global routing infrastructure.  As my colleague Andrei Robachevsky wrote in his Rough Guide to IETF 92 post:

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see

This issue of “route leaks” is one that comes up repeatedly and is causing problems on the global Internet. For instance, yesterday DynResearch tweeted about a route hijack of Google’s site by Belarus Telecom – now I don’t know if that was an actual “route leak”, but it’s the kind of routing issue we do see often on the Internet… which is why this class of issues needs to be identified and solutions proposed.

And just because we really want to be in three places at once… over in the Venetian Room during this same 1520-1620 time block will be the “Automated Certificate Management Environment (ACME)” BOF looking at ways to automate management of TLS certificates. As the agenda indicates, the session is primarily about discussing draft-barnes-acme and the efforts being undertaken as part of the Let’s Encrypt initiative.  The ideas are intriguing and proposals that help automate the security of the Internet can certainly help reduce the friction for regular users.

After all of that is over we’ll be joining in for the Operations and Administrative Plenary from 1640-1910 CDT.  You can view a live video stream of the plenary at    And then… we’ll be getting ready for Day 4…

For some more background, please read these Rough Guide posts from Andrei, Phil and I:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Olaf Kolkman of Jen Linkova at IETF 92. Part of a larger set of IETF 92 photos Olaf has published.

TLS-O-MATIC Now Available To Test TLS In Applications

TLS-O-MATIC logoDo you want to test how well your application supports TLS over HTTP?  If so, you can now head over to:

and run your application through a whole series of self-tests.

As he explains in a blog post announcing TLS-O-MATIC, Olle Johansson launched the site as a public service with 15 tests for the HTTPS protocol.

I’ve known Olle for many years through his work seeking to add security to various voice-over-IP (VoIP) services and protocols – and in recent years he has been focused around the idea of getting more encryption deployed.  He typically uses the “#MoreCrypto” hashtag on Twitter and other services – and we wrote about his #MoreCrypto 2.0 slide deck he released back in December 2014.

Some of the tests included in TLS-O-MATIC are:

  • Bad hostname
  • One cert, multiple names
  • Wildcard certificate
  • Not yet valid certificate
  • Expired certificate
  • Unknown CA
  • Client certificate
  • Weak certificate
  • Intermediate certificate
  • Chain of trust
  • A huge certificate
  • A strong key
  • Wrong usage bits
  • Server Name Indication
  • International DNS

We applaud Olle for making this test site available and hope it will be helpful to application developers to test if their applications fully support TLS.  If you are an application developer, please do visit the site and give Olle any feedback you may have as you use it.

Sites like this can help make encryption available everywhere and bring about a stronger and more secure Internet!

Today’s VUC Google+ Hangout About “Moving The Web To HTTPS”

It’s a bit late-notice for many of you, I realize, but in about 1.5 hours at 12 noon US EST (17:00 UTC) today, the “IP Communications & VoIP Community” will be having a Google+ Hangout on Air on topic of “MoreCrypto: Moving the Web to HTTPS”. Given that this relates to our TLS For Applications topic area, I thought it might be of interest – and I’m intending to join myself.  For more info and the link to watch just click/tap the image:

VUC 526

As noted on the VUC episode page, the speaker is:

Daniel Appelquist, who describes himself as an “open web advocate”, joins us to talk about TLS on the web: some good reasons for using it and the common objections to it. As someone with a very wide experience in IP and network communications, a session with Dan and our VUC regulars should be excellent!

Dan is also a co-chair of the W3C Technical Architecture Group (W3C TAG). The TAG is a special working group within the W3C, chartered (under the W3C Process Document) with stewardship of the Web architecture.

The session will be recorded for later viewing at that same link.


Olle Johansson’s #MoreCrypto V2.0 Slide Deck – With TLS

Olle Johansson is a tireless crusader for bringing about a more secure Internet… and just recently published a new version 2.0 of his “#MoreCrypto” slide presentation that this time incorporates a good bit more information about TLS. He includes some tutorial information about TLS and gives multiple examples of using certificates, including with the DANE protocol.

If you are looking to come up to speed on how we make the Internet more secure as well as why it is important, the deck is very useful.  We do encourage you to check it out!

And when you’re done, why not head over to our “TLS for Applications” area to learn more about adding TLS to your applications?  Or visit our Start Here page to get started with IPv6, DNSSEC, TLS and more?

P.S. Olle is always open to feedback about his slides, too… you can reach him at

Make Encryption The Norm For All Internet Traffic, Says The Internet Architecture Board (IAB)

Internet Architecture Board (IAB)The Internet Architecture Board announced a new “Statement on Internet Confidentiality” yesterday that calls on “protocol designers, developers, and operators to make encryption the norm for Internet traffic“.  The statement, distributed via email by IAB Chair Russ Housely, goes further in urging those who design and develop new protocols “to design for confidential operation by default“.

The strong statement, republished below, represents the continued evolution of the thinking of the wider technical community, as represented by the IAB and the IETF,  that in light of the disclosures of massive pervasive monitoring of the Internet (see RFC 7258) the technical infrastructure of the Internet needs to be strengthened against those attacks.

As the IAB statement notes, such a move to make encryption the default will have impacts on some aspects of current network operations, but the statement represents the very public commitment by the IAB to help create the conditions under which, as it says, we can “move to an Internet where traffic is confidential by default.”

From our perspective here at Deploy360, we definitely welcome this statement as it will help the overall security of the Internet.  Within the topics we cover here, we encourage developers to look at adding TLS to all their applications, and we encourage network operators to do all they can to help their customers use TLS-encrypted applications wherever possible.  We are also looking forward to continued discussions such as those held in the DPRIVE Working Group this week at IETF 91 that will improve the confidentiality and privacy of DNS interactions as well as those within the routing infrastructure.

Here is the full IAB Statement on Internet Confidentiality:

IAB Statement on Internet Confidentiality

In 1996, the IAB and IESG recognized that the growth of the Internet depended on users having confidence that the network would protect their private information. RFC 1984 documented this need. Since that time, we have seen evidence that the capabilities and activities of attackers are greater and more pervasive than previously known. The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic. Encryption should be authenticated where possible, but even protocols providing confidentiality without authentication are useful in the face of pervasive surveillance as described in RFC 7258.

Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation. Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation. There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation.

We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected.

The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic.

We believe that each of these changes will help restore the trust users must have in the Internet. We acknowledge that this will take time and trouble, though we believe recent successes in content delivery networks, messaging, and Internet application deployments demonstrate the feasibility of this migration. We also acknowledge that many network operations activities today, from traffic management and intrusion detection to spam prevention and policy enforcement, assume access to cleartext payload. For many of these activities there are no solutions yet, but the IAB will work with those affected to foster development of new approaches for these activities which allow us to move to an Internet where traffic is confidential by default.

We’re looking forward to working with all of you there to bring about this Internet where traffic is encrypted by default!