Category: Security

Dec 07

WhatsApp and End-to-End Encryption (a ChatGPT3 article experiment)

For those who use WhatsApp, you may have noticed that your messages are secure and private, thanks to the encryption that is used. But what is encryption, and why is it so important?

Encryption is a process of scrambling information so that only the intended recipient can read it. Essentially, it takes the data you’re sending and scrambles it using a mathematical algorithm. To unscramble the data, you need a key, which is known only to the sender and the receiver.

WhatsApp uses end-to-end encryption, which means that your messages are encrypted on the sender’s device, travel securely to the receiver’s device, and remain encrypted until the receiver reads them. This means that no one – not even WhatsApp themselves – can see the messages you’re sending.

This is an important feature for anyone concerned about their privacy, especially in an era of increased surveillance. With WhatsApp’s encryption, you can be sure that your messages will stay safe, secure, and private.

WhatsApp is also working to improve their encryption, with plans to add a feature known as “Perfect Forward Secrecy”. This feature will generate a new encryption key for each message you send, ensuring that if one key is ever compromised, the others will remain safe.

Encryption is an important part of keeping our messages secure, private, and confidential. Thanks to WhatsApp’s use of encryption, we can be sure that our messages are safe and secure.

 

— A second version — 


In the age of increasing concern over privacy and security, end-to-end encryption has become an essential part of secure communication. WhatsApp, the popular messaging and voice-over-internet-protocol (VOIP) application, has been at the forefront of this movement, using the strong encryption protocols to keep users' conversations secure.

WhatsApp uses the Signal Protocol, an open-source encryption protocol developed by Open Whisper Systems, for its communications. The Signal Protocol is considered to be one of the most secure encryption protocols available, and is used by other popular messaging services such as Facebook Messenger, Google Allo, and Skype.

Using the Signal Protocol, WhatsApp transmits messages between users in an encrypted form, meaning that only the sender and recipient can see the contents of the message. This makes it impossible for third-party entities, such as government agencies or hackers, to read or intercept the messages. The encryption is also applied to all media messages, including photos, videos, and audio recordings, as well as group messages.

WhatsApp also uses a two-factor authentication system for added security. This means that users must enter a code sent to their phone before they can access their account. This provides an extra layer of protection that makes it difficult for hackers to gain access to user accounts.

Overall, WhatsApp's use of encryption is a great step forward in protecting users' privacy and security. The Signal Protocol provides a secure communication medium, and the two-factor authentication system helps ensure that users' accounts are secure. It's no wonder that WhatsApp is used by millions of people around the world.

 

— A third version — 

Recently, WhatsApp announced that it is now using end-to-end encryption for all its communications. This means that all messages, pictures, audio and video files sent through the popular messaging app will be encrypted so that only the sender and recipient can view or hear them.

WhatsApp's use of encryption is a huge step forward in protecting user privacy. With end-to-end encryption, even the company itself can't access the content of messages sent through its service, meaning that users can be sure that their conversations remain private. The encryption also makes it much harder for hackers or other malicious actors to intercept messages, protecting users from potential data breaches.

The encryption also has implications for businesses and organizations that use WhatsApp for communications. By securing messages with end-to-end encryption, companies can be sure that their confidential conversations remain private, even if an employee's device is hacked. This added layer of security can help protect businesses from potential data breaches, and also provide a higher level of assurance to customers who are sending sensitive information.

WhatsApp's use of encryption is a welcome move that will help protect user privacy and data security. It's a great example of how technology can be used to improve security and protect user data.

 

— Why three versions? — 

All three of these were “written” by the ChatGPT service using the prompt "Write a blog post about WhatsApp's use of encryption in the style of Dan York”. I just refreshed it to get another version. I used the default settings except for changing the maximum length to 1100

They’re not bad, eh?

The text is not entirely off from what I would normally write on my sites. I put a strikethrough on the last sentence of the first two because those were sentences I don’t think I would ever write. They feel a bit overly promotional. I included them just to show what ChatGPT would produce.

Certainly text like this could generate a quick “first draft” that I could then edit a bit to publish.

Would you have known that I did not write them if I didn’t indicate it was from ChatGPT?

We live in interesting times… 

 

Oct 04

Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018

skeleton key

Are you ready? Are your systems prepared so that DNS will keep functioning for your networks?  One week from today, on Thursday, October 11, 2018, at 16:00 UTC ICANN will change the cryptographic key that is at the center of the DNS security system – what we call DNSSEC. The current key has been in place since July 15, 2010. This is a long-planned replacement.

If everything goes fine, you should not notice and your systems will all work as normal. However, if your DNS resolvers are not ready to use the new key, your users may not be able to reach many websites!

This change of this central security key for DNS is known as the “Root Key Signing Key (KSK) Rollover”. It has been in discussion and planning since 2013. We’ve written many articles about it and spoken about it at many conferences, as have many others in the industry. ICANN has a page with many links and articles at:

But here we are, with only a few days left and you may be wondering – how can I know if my systems are ready?

The good news is that since the Root KSK Rollover was delayed 1 year, most all of the DNS resolver software has been shipping for quite some time with the new key. If you, or your DNS server administrators, have been keeping up with recent updates, you should be all set.

1. Test if you are doing DNSSEC validation

Before you do anything else, you should first check if you are doing DNSSEC validation on your network.  As noted in ICANN’s guidance document, go to a command-line / terminal / shell window and type:

dig @<IP of your DNS resolver> dnssec-failed.org a +dnssec

For example, using Google’s Public DNS Server, the command would be:

dig @8.8.8.8 dnssec-failed.org a +dnssec

If the response includes this text:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

then you ARE doing DNSSEC validation and should read the rest of this article.

If the response instead includes:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

… well, you are NOT doing DNSSEC validation. You can skip the rest of this article, go have a beverage, and not have to worry about the Root KSK Rollover on October 11.  However, you should also read up on DNSSEC and understand why you start validating to raise the level of security and trust on your network. (But, at this point, you might as well wait until October 12 to deploy it.)

If you are doing DNSSEC validation, read on. 

Two notes:

  • Unfortunately if you are not an administrator of your DNS resolvers, there are limited mechanisms to check if you have the new key. There are a couple of possibilities (see #2 and #3a below), but otherwise you will need to contact your DNS administrators / IT team and point them to this blog post and other resources.
  • In DNS / DNSSEC circles the root key is also referred to as a “trust anchor”.

2. Try the Sentinel KSK Test

For a small percentage of you reading this, you might be able to use the “sentinel test” that is based on an Internet draft that is in development. You can do so at either of these sites:

Right now there is only one DNS resolver (Unbound) that implements this sentinel test. Hopefully by the time we do the next Root KSK Rollover, some years from now, this will be more widely deployed so that regular users can see if they are protected.

However, for most of us, myself included, we need to go on to other methods…

3a. Check if your DNS resolvers have the new Root KSK installed – via various tools

There are several tests you may be able to perform on your system. ICANN has published a list at:

That document lists the steps for the following DNS resolvers:

  • BIND
  • Unbound
  • PowerDNS Recursor
  • Knot Resolver
  • Windows Server 2012RS and 2016
  • Akamai DNSi Cacheserve
  • Infoblox NIOS

For BIND users, ISC2 also provides a focused document: Root KSK Rollover in BIND.

3b. Check if your DNS resolvers have the new Root KSK installed – via specific files

If you have command-line access to your DNS servers, you can look in specific files to see if the new key is installed.  The current key (“KSK 2010”) has an ID of 19036. The new key has an ID of 20326. As Paul Wouters wrote in a Red Hat blog post today, these keys can be found in these locations in Red Hat Linux:

  • bind – see /etc/named.root.key
  • unbound / libunbound – see /var/lib/unbound/root.key
  • dnsmasq – see /usr/share/dnsmasq/trust-anchors.conf
  • knot-resolver – see /etc/knot-resolver/root.keys

Look in there for a record with an ID of 20326. If so, you are all set. If not, you need to figure out how to get the new key installed.

Note – these locations here are for Red Hat Linux. Other Linux distributions may use slightly different file locations – the point is that there should be a file somewhere on your system with these keys.

4. Have a backup plan in case there are problems

As Paul notes in his post today, it would be good to have a backup plan in case there are unexpected DNS problems on your network on October 11 and users are not able to resolve addresses via DNS. One suggestion is to temporarily change your systems to give out one of the various sets of “public” DNS servers that are operated by different companies. Some of these include:

IPv4 IPv6 Vendor
1.1.1.1 2606:4700:4700::1111 Cloudflare
8.8.8.8 2001:4860:4860::8888 Google DNS
9.9.9.9 2620:fe::fe Quad9
64.6.64.6 2620:74:1b::1:1 Verisign

You can switch to one of these resolvers while you sort out the issues with your own systems. Then, once you have your systems correctly configured, you can switch back so that the DNSSEC validation is happening as close to your users as possible (thereby minimizing the potential areas of the network where an attacker could inject malicious DNS traffic).

5. Plan to be around on 11 October 2018 at 16:00 UTC

Finally, don’t schedule a day off on October 11th – you might want to be around and able to monitor your DNS activity on that day.  This Root KSK Rollover has been in the works for many years now. It should be a “non-event” in that it will be “just another day on the Internet”. But many of us will be watching whatever statistics we can. And you’ll probably find status updates using the #KeyRoll hashtag on Twitter and other social networks.

The end result of all of this will be the demonstration that we can safely and securely change the cryptographic key at the center of DNS – which allows us to continue improving the level of security and trust we can have in this vital part of the public core of the Internet!

Image credit: Lindsey Turner on Flickr. CC BY 2.0

P.S. This is NOT what the “Root key” looks like!

Acknowledgements:  Thanks to Ed Lewis, Paul Hoffman, Paul Wouters, Victoria Risk, Tony Finch, Bert Hubert, Benno Overeinder, Hugo Salgado-Hernández, Carlos Martinez and other members of the dnssec-coord discussion list for the discussion that informed this post.

The post Are you ready? How to prepare for the DNSSEC Root KSK Rollover on October 11, 2018 appeared first on Internet Society.

Jun 22

Watch Live On Monday, 25 June – DNSSEC Workshop at ICANN 62 in Panama

With the DNSSEC Root Key Rollover coming up on October 11, how prepared are we as an industry? What kind of data can we collect in preparation? What is the cost benefit (or not) of implementing DANE? What can we learn from an existing rollover of a cryptographic algorithm?

All those questions and more will be discussed at the DNSSEC Workshop at the ICANN 62 meeting in Panama City, Panama, on Monday, June 25, 2018. The session will begin at 9:00 and conclude at 12:15 EST (UTC-5). [Note: this is one hour different than current US Eastern Daylight Time – Panama does not change to daylight savings time – and so this will begin at 10:00 EDT (UTC-4).]

The agenda includes:

  • DNSSEC Workshop Introduction, Program, Deployment Around the World – Counts, Counts, Counts
  • Panel: DNSSEC Activities and Post Key Signing Key Rollover Preparation
  • DANE: Status, Cost Benefits, Impact from KSK Rollover
  • An Algorithm Rollover  (case study from CZ.NIC)
  • Panel: KSK Rollover Data Collection and Analysis
  • DNSSEC – How Can I Help?
  • The Great DNSSEC/DNS Quiz

It should be an outstanding session!  For those onsite, the workshop will be in Salon 4, the ccNSO room.

Lunch will follow. Thank you to our lunch sponsors: Afilias, CIRA, and SIDN.

The DNSSEC Workshop will be followed by the “Tech Day” set of presentations from 13:30 – 18:30 EST. Many of those may also be of interest. They will also be streamed live at the same URL.

As this is ICANN’s smaller “Policy Forum” schedule, there will not be either the “DNSSEC for Everybody” session nor the “DNSSEC Implementer’s Gathering” as there is at the other two ICANN meetings each year. Also, as I am not able to travel to ICANN 62, I want to thank Jacques Latour for stepping in to help with the usual presenting and emceeing that I do.

Please do join us for a great set of sessions about how we can work together to make the DNS more secure and trusted!

If you would like more information about DNSSEC or DANE, please visit our Start Here page to begin.

Image credit: ICANN

The post Watch Live On Monday, 25 June – DNSSEC Workshop at ICANN 62 in Panama appeared first on Internet Society.

Jun 05

Watch live – June 6 panel on “Innovation, security, and the Internet of Things (IoT)” in Ottawa

As a side event before the 2018 G7 Summit this week in Canada, tomorrow, 6 June 2018, the Internet Society will hold a panel to not only talk about the risks and opportunities the Internet of Things (IoT) brings, but also what policy makers can do to build a connected future for everyone.

The panel, Innovation, security, and the Internet of Things, will take place in Ottawa Ontario. If you’re in Ottawa, you can join us from 7:30 to 9:30 a.m. on Wednesday, 6 June, at the Alt Hotel Ottawa at 185 Slater St. If you’re somewhere else, the event will be
livestreamed.

Moderator David Akin (Global News) will facilitate a discussion between:

  • Jeff Wilbur, Director, Online Trust Alliance
  • Katie Watson, Policy Advisor, Internet Society
  • Jacques Latour, Chief Technology Officer, Canadian Internet Registration Authority
  • Mike Hoye, Engineering Community Manager, Mozilla

While the opportunities these connected devices can bring us are virtually unprecedented, the steps we must go through to protect ourselves online can feel overwhelming. At the Internet Society, we believe in a future where manufactures, software developers and service providers put people first and ensure user’s privacy and security is their top priority.

To understand more, you can listen to Mark Buell, North American Bureau Director, explain why a secure and open Internet is important, what we expect from G7 leaders, and what to expect from the expert panel discussion on the topic (audio, 6 minutes):

Learn more:

The post Watch live – June 6 panel on “Innovation, security, and the Internet of Things (IoT)” in Ottawa appeared first on Internet Society.

May 24

Podcast: Talking Data Privacy and GDPR with Todd Tolbert

“Let’s raise the bar on data privacy and make the Internet safer.”  With the imminent arrival of the EU’s General Data Protection Regulation (GDPR), this was one of the points raised by Todd Tolbert, our Chief Administrative Officer, in an episode of the Non-Profit Tech Podcast published yesterday. Hosted by fusionSpan’s Justin Burniske, the 35-minute episode covered a wide range of topics, including:

  • the difference between data privacy and data protection
  • Todd’s thinking about the value the GDPR brings in terms of thinking about data
  • mistakes organizations make with regard to handling their data
  • resources for organizations to do more
  • how you can’t be liable for data that you don’t have in the first place
  • asking the question… do you really need to keep those 700 email addresses that no longer work?

And, of course, Todd being who he is, there were some Texan things mixed in to the conversation as well. I very much enjoyed the episode and found it a useful contribution to the ongoing privacy discussions that tomorrow’s GDPR deadline has generated.

Some of the resources Todd shared included:

I would also encourage you to view our articles and resources related to privacy.

Since I can’t seem to find any way to embed the player here, you’ll need to go visit the podcast page to listen – or download it in your favorite podcast app.

FYI, as Todd as written previously, he’s been leading our efforts on GDPR compliance, and also serves as our Data Privacy Office (DPO).

The post Podcast: Talking Data Privacy and GDPR with Todd Tolbert appeared first on Internet Society.

Apr 16

At RSA USA 2018 in San Francisco this week? Join the IoT Security conversation on Tuesday, April 17

Are you attending the RSA USA 2018 Conference this week in San Francisco? If so, please plan to join this panel session happening Tuesday, April 17, 2018, from 3:30 – 4:14pm (PDT):

IoT Trust by Design: Lessons Learned in Wearables and Smart Home Products

Moderated by my colleague Jeff Wilbur, Director of the Online Trust Alliance (OTA), the panel abstract is:

The world has awakened to the need for tighter security and privacy in consumer-grade IoT offerings. This panel will present a trust framework for IoT, and wearable and smart home experts will discuss top attack vectors, typical vulnerabilities in devices, apps and systems, common reasons for design compromise, the evolution of security and privacy in IoT and where it needs to go.

They will be discussing the OTA’s IoT Trust Framework, as well as some new mechanisms available to help enterprises understand the risks associated with IoT devices.

If you believe securing the Internet of Things is a critical step to having a secure Internet, please join Jeff and his panelists to learn more.

Unfortunately there appears to be no live stream available but they do seem to be recording many of the sessions. If Jeff’s session is recorded we will update this post and our event page with that information once the recording is published.

We will be posting updates to our blog and our RSA USA 2018 event page. You can follow our updates on Twitter at @InternetSociety. You can also follow the #RSAC hashtag on Twitter for updates about the overall conference.

The post At RSA USA 2018 in San Francisco this week? Join the IoT Security conversation on Tuesday, April 17 appeared first on Internet Society.

Mar 16

Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy

It’s going to be a crazy busy week in London next week in the world of DNS security and privacy! As part of our Rough Guide to IETF 101, here’s a quick view on what’s happening in the world of DNS.  (See the full agenda online for everything else.)

IETF 101 Hackathon

As usual, there will be a good-sized “DNS team” at the IETF 101 Hackathon starting tomorrow. The IETF 101 Hackathon wiki outlines the work (scroll down to see it). Major security/privacy projects include:

  • Implementing some of the initial ideas for DNS privacy communication between DNS resolvers and authoritative servers.
  • Implementation and testing of the drafts related to DNS-over-HTTPS (from the new DOH working group).
  • Work on DANE authentication within systems using the DNS Privacy (DPRIVE) mechanisms.

Anyone is welcome to join us for part or all of that event.

Thursday Sponsor Lunch about DNSSEC Root Key Rollover

On Thursday, March 22, at 12:30 UTC, ICANN CTO David Conrad will speak on “Rolling the DNS Root Key Based on Input from Many ICANN Communities“. As the abstract notes, he’ll be talking about how ICANN got to where it is today with the Root KSK Rollover – and about the open comment period on the plan to roll the KSK in October 2018.

David’s session will be streamed live for anyone wishing to view remotely.

DNS Operations (DNSOP)

The DNS sessions at IETF 101 really begin on Tuesday, March 20, with the DNS Operations (DNSOP) Working Group from 15:50 – 18:20 UTC. Several of the drafts under discussion will relate to the Root KSK Rollover and how to better automate and monitor key rollovers. DNSOP also meets on Thursday, March 22, from 18:10-19:10, where one draft of great interest will be draft-huque-dnsop-multi-provider-dnssec. This document explores how to deploy DNSSEC in environments where multiple DNS providers are in use. As per usual, given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 UTC.  As shown on the agenda, there will be two major blocks of discussion. First, Sara Dickinson will offer recommendations for best current practices for people operating DNS privacy servers. This builds off of the excellent work she and others have been doing within the DNS Privacy Project.

The second major discussion area will involve Stephane Bortzmeyer discussing how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  When the DPRIVE working group was first chartered, the discussion was whether to focus on the privacy/confidentiality between a stub resolver and the local recursive resolver; or between the recursive resolver and authoritative server; or both. The discussion was to focus on the stub-to-recursive-resolver connection – and that is now basically done from a standards perspective. So Stephane is looking to move the group on into the next phase of privacy. As a result, the session will also include a discussion around re-chartering the DPRIVE Working Group to work on this next stage of work.

Extensions for Scalable DNS Service Discovery (DNSSD)

On a similar privacy theme, the DNSSD Working Group will meet Thursday morning from 9:30-12:00 UTC and include a significant block of time discussing privacy and confidentiality.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information. draft-ietf-dnssd-privacy-03 and several related drafts explore how to add privacy protection to this mechanism. The DNSSD agenda shows more information.

DNS-Over-HTTPS (DOH)

IETF 101 will also feature the second meeting of one of the working groups with the most fun names – DNS Over HTTPS or… “DOH!” This group is working on standardizing how to use DNS within the context of HTTPS. It meets on Thursday from 13:30-15:30. As the agenda indicates, the focus is on some of the practical implementation experience and the work on the group’s single Internet-draft: draft-ietf-doh-dns-over-https.

DOH is an interesting working group in that it was formed for the express purpose of creating a single RFC. With that draft moving to completion, this might be the final meeting of DOH – unless it is rechartered to do some additional work.

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s Wednesday meeting. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 101:

DNSOP (DNS Operations) WG
Tuesday, 20 March 2018, 15:50-18:30 UTC, Sandringham
Thursday, 22 March 2018, 18:10-19:10 UTC, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 21 March 2018, 13:30-15:00 UTC, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 22 March 2018, 9:30-12:00 UTC, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DOH (DNS over HTTPS) WG
Thursday, 22 March 2018, 13:30-15:30 UTC, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/doh/
Documents: https://datatracker.ietf.org/wg/doh/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

The post Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy appeared first on Internet Society.

Jan 04

Meltdown and Spectre: Why We Need Vigilance, Upgradeability, and Collaborative Security

Today the tech media is focused on the announcement of two security vulnerabilities, nicknamed Meltdown and Spectre, that are found in almost all CPUs used in modern devices. Mobile phones, laptops, desktop computers, cloud services, and Internet of Things (IoT) devices are all vulnerable.

There are many articles being published on this topic. The best source of information I’ve found is this site by the security researchers at the Graz University of Technology:

https://meltdownattack.com/

At the bottom of that page are links to the security blog posts, advisories, and other statements from companies and organizations across the industry. In an excellent example of the principles of Collaborative Security, the announcement was coordinated with the release of patches and updates for a wide range of operating systems and devices.

For readers wanting a deeper technical dive, the site from Graz University has links to multiple academic papers. Google’s Project Zero team also published a detailed technical analysis.

From our perspective, today’s news highlights a couple of points:

  • Keeping up to date on patches is critical. We each need to ensure that we upgrade our own systems and devices. If we work for organizations/companies, we need to ensure that processes are in place for patches to be applied rapidly. Vigilance is critical.
  • “Upgradeability” is necessary. We’ve mentioned this particularly in the IoT context, but devices need to be able to be upgraded. They can’t just be distributed or sold to people without some mechanism for updates. We see approaches such as the Online Trust Alliance IoT Framework as critical to help on this issue.
  • Independent security research is essential. These vulnerabilities were discovered by different groups of researchers at companies, security firms, and universities. If we didn’t have people doing this research for the benefit of all of us, we would be open to attacks by those who might find these vulnerabilities and exploit them for malicious purposes.
  • Collaborative security is the key. Sharing this research – and coordinating activity across the industry – is critical to ensuring a secure and trusted Internet.  We need the kind of collaboration shown today to be the norm across the industry.

The key point right now for everyone reading this is simply this: get out there and patch your systems! Don’t delay installing the latest security updates for your computers, mobile phones and other devices.

Each of us play a critical role in ensuring the security of an open, global and trusted Internet!

The post Meltdown and Spectre: Why We Need Vigilance, Upgradeability, and Collaborative Security appeared first on Internet Society.

Jul 10

Rough Guide to IETF 99: DNS Privacy and Security, including DNSSEC

There’s a good bit of DNS secrurity and privacy activity happening at IETF 99 next week in Prague, although not all of that is in working groups. Here is a view of what is going on.

IETF 99 Hackathon

Once again there will be a good-sized “DNS team” at the IETF 99 Hackathon over the weekend (15-16 July). The IETF 99 Hackathon wiki outlines the work (scroll down to see it). From a security point of view, major projects include:

  • Continuing work on how DNS implementations deal with the impending KSK rollover in October 2017.
  • RFC 5011 compliance testing (related to the KSK rollover)
  • Implementation of the new elliptic curve crypto algorithm, Ed25519, defined in RFC 8080.

There is also work on multiple other DNS records and tools, including a new packet capture format focused on DNS. Anyone is welcome to join us for part or all of that event.

DNS Privacy Tutorial

On Sunday, July 16, there will be a “DNSPRIV Tutorial” from 12:30-13:30 CEST (UTC+2). This will explain the work of the DPRIVE working group to add a layer of confidentiality to DNS queries. Much of this involves sending DNS queries over TLS.

It is possible (and I’ll update the post if it is) that this tutorial may be streamed out over the IETF YouTube channel and recorded. The www.ietf.org/live page doesn’t have it listed yet, but I would check there to see closer to the date.

DNS PRIVate Exchange (DPRIVE)

On the same theme, the DPRIVE working group meets Tuesday morning from 9:30-12:00 CEST.  The draft agenda shows their should be good discussion on several of the current working group drafts. I am also looking forward to the discussion about DNS over the QUIC protocol. The group will also discuss measuring the usage of DNS-over-TLS and talk about what comes next.

DNS Operations (DNSOP)

The DNS Operations (DNSOP) Working Group meets twice in Prague. First on Tuesday, July 18, from 15:50-17:50 CEST, and then on Thursday, July 20, from 18:10-19:10.

The agenda isn’t out yet, but two drafts related to DNSSEC that might be up for discussion include:

There are a range of the other documents related to DNS security or privacy – or that can have impacts on those topics. We’ll have to see what gets onto the agenda.

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

The DNS-SD working group will also have a brief discussion of DNS-SD Privacy drafts. Agendas aren’t posted yet, but the Using TLS in Applications (UTA) working group often has drafts of interest, as does the Security Area Open Meeting (SAAG). The thing about DNS is that it is so critical to every service that it often shows up in many different groups.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 99:

DPRIVE (DNS PRIVate Exchange) WG 
Tuesday, 18 July 2017, 09:30-12:00 CEST (UTC+2), Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dprive/ 
Documents: https://datatracker.ietf.org/wg/dprive/ 
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSOP (DNS Operations) WG 
Tuesday, 18 July 2017, 15:50-17:50 CEST (UTC+2), Congress Hall II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dnsop/ 
Documents: https://datatracker.ietf.org/wg/dnsop/ 
Charter: http://tools.ietf.org/wg/dnsop/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG 
Wednesday, 19 July 2017, 15:20 – 16:50 CEST (UTC+2), Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dnssd/ 
Documents: https://datatracker.ietf.org/wg/dnssd/ 
Charter: http://tools.ietf.org/wg/dnssd/charters/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://www.internetsociety.org/rough-guide-ietf99.

The post Rough Guide to IETF 99: DNS Privacy and Security, including DNSSEC appeared first on Internet Society.

Jun 27

New Petyawrap Ransomware Attack Again Highlights Critical Need For Security Processes

Whenever there’s a new attack on a global scale, the world trusts the Internet a little less. Today we are concerned with the many reports about this new ransomware attack called “Petyawrap”, “Petrwrap” or an older name of “Petya.”

The sad fact is: this new attack exploits the same vulnerabilities in Windows systems as last month’s WannaCry attack. 

Fixes have been available for most Windows systems since March 2017!

The same tips Niel Harper provided last month to protect against ransomware also apply here.

Why haven’t the updates been applied? Often, smaller organizations may not have the needed IT staff. Enterprises may not fully embrace the level of business continuity planning they need. Companies may have legacy systems that are hard to patch.

Many organizations may have thought they were “safe” when they weren’t hit by WannaCry. They may have breathed a sigh of relief – and moved on to other critical needs.

The bad news is that this new attack gets nastier after the initial penetration of a network. Dan Goodin at ArsTechnia relays that the attack payload includes tools to extract user passwords. It can then infect other systems on your network using those credentials. Microsoft has more technical details. Unlike WannaCry, there seems to be no “kill switch” to stop the infections. (See update below.)

As Olaf Kolkman wrote last month in response to the WannaCry ransomware:

“When you are connected to the Internet, you are part of the Internet, and you have a responsibility to do your part.”

But yet as Brian Krebs reports at the end of his excellent piece, a recent ISACA survey found that:

  • 62 percent of organizations surveyed recently reported experiencing ransomware in 2016
  • only 53 percent said they had a formal process in place to address it

These attacks cause significant economic losses. They erode trust in the Internet. They limit the opportunities we all have online.

Collaborative security is a shared responsibility. We all have a part to play. We need to put the security processes in place to reduce these threats. In our companies and organizations. In nonprofits, schools, and community groups. In our homes. In our own actions.

We have the opportunity to shape tomorrow and build a stronger, more trusted Internet. One where ransomware no longer hits on a global scale. 

Read Niel’s 6 tips. Promote the approach of “Collaborative Security“. Develop and implement security management strategies. Ask strong questions inside your organization.

Take action.

The time is now.

——

UPDATE #1 – There are now reports of a “vaccine” in the form of a file you can create on a Windows system to prevent the ransomware from running. This is not a “kill switch” that can apply globally, but it is something that can be done on individual PCs. If the ransomware finds that this read-only file exists, it will not perform its attack on that machine.

——

See also our past articles about the WannaCry attacks:

The post New Petyawrap Ransomware Attack Again Highlights Critical Need For Security Processes appeared first on Internet Society.