Basic Conference Travel Cybersecurity Advice

I wrote up some fairly off-the-cuff travel cybersecurity advice back in 2022 for a client, and it’s generic and useful and still current enough that I thought I would post a lightly-edited version here.

Its audience is mostly-US persons and US-based organizations traveling abroad for conferences in a professional capacity, although I think it is fairly applicable outside that.  This advice is also specifically not for people who believe they are or may be actively targeted!

Obviously in fall 2025 the risk calculus, particularly for non-US persons traveling to the US, is changing very rapidly, and without doing substantially more reading and thinking I don’t feel I can give good advice to that specifically.  I do think the advice here still provides a good, safe baseline for everyone, and additional measures can be layered on top as you need and desire.

---

tl;dr:

1. If you are ever concerned that your device may have been compromised, stop whatever you’re doing and reboot it immediately.
2. Take your software updates, always, but especially before you travel.
3. Don’t click through certificate warnings on public WiFi!

How come? Read on.

This is a lot less formal than my usual threat models, but we’re considering less well-defined systems here.

First and most important piece of advice: If you are ever concerned that your device may have been compromised, stop whatever you’re doing and reboot it immediately.

Modern operating systems, especially Apple OSes, and especially Apple’s mobile OSes and ChromeOS, do a very good job of making it hard for attackers to get what we call ‘persistence’, that is, the ability to retain access to your device across reboots.

Most vulnerabilities which allow an attacker to gain initial access to your device are memory corruption vulnerabilities.  The attacker effectively sends some data to a running program on your device which that program loads into its memory and then mistakenly interprets as code, giving the attacker the ability to run arbitrary code as that program.

One very common way this plays out in practice is that an attacker might send you an email claiming to be your bank with a malicious PDF attachment.  When you open the PDF with your system PDF viewer, if the attacker has been clever and crafty enough, they may be able to trick the system PDF viewer into treating some of the data in that PDF as the system PDF viewer’s own code.[1]

However, once that program is killed or the device is rebooted, its memory is cleared, the attacker’s code will no longer be running on the system, and the attacker would need to send the same data again to re-exploit the vulnerability.[2]  (Especially challenging, expensive, and risky if some user interaction is required, as in phishing.)

In order to survive this, the attacker usually needs to write some code to disk, somewhere that the system will load it automatically the next time the system reboots.  All modern operating systems make this nontrivial, although sometimes individual software packages can be (mis)configured in such a way that it’s fairly straightforward.[3]

However, the best OSes, like the aforementioned Apple mobile OSes and ChromeOS, make it so hard that vulnerabilities which just get the attacker on to the system and out of the sandbox go for at least a million dollars, and vulnerabilities which allow the attacker persistence go for tens or hundreds of millions of dollars.[4]

Second and nearly-most important piece of advice: Take your software updates, always, but especially before you travel.  The overwhelming majority of real-world compromises come not from attackers finding undisclosed security bugs in software (what we call “zero-days”) and using them.

Instead, attackers read the changelogs of popular software, note when they patch a spicy security bug, and then use it against everybody who hasn’t upgraded to the newest version yet.  (It’s cheaper and less work for them!  Attackers are, like all of us, fundamentally lazy trying to maximize their effectiveness for a given amount of effort.)

Particularly before going to a sensitive event I make a point to take all of the OS and application-level software updates available to me (iOS/Android, macOS/Windows/Linux, Office/Creative Cloud/etc).  Automatic updates are getting increasingly reliable, but Apple in particular does staged rollouts, so you can’t rely on waiting for the “it’s time to update” notification, I usually need to click into Settings -> General -> Software Updates, check if anything is available, which it often is, and manually initiate the update process.

Third and final piece of advice: Don’t click through certificate warnings on public WiFi!

For years there has been a lot of public concern and warnings about the insecurity of public WiFi, and this is one of many places where our advice, while more valid twenty years ago, has not caught up with the progress we’ve made on security and is no longer applicable.

In an era where the overwhelming majority of traffic on the public web is secured with HTTPS, one no longer needs to use a VPN or worry about doing sensitive transactions on public WiFi, and in fact using a VPN can put one at more risk than not.

If you ever need a non-HTTPS site, for example to trigger the login screen on a public WiFi hotspot, there are good options like neverssl.com.

However, should you ever be unexpectedly presented with a screen like this while on public WiFi, don’t click through it!  This is likely a sign that something bad is happening that you want no part of.

And that’s mostly it.  Safe travels!

 

---

Footnotes:

[1]:  Opening PDFs in a web browser like Chrome is substantially safer, which is why most browsers default to it at this point.  You can think of a web page in 2022 as basically a program that you download from an unknown, arbitrary, potentially adversarial source and run locally on your computer, and so the major browser vendors have done a truly Herculean amount of work to build a “sandbox” in which it’s safe to do so and very hard for stuff inside to get out.  This then makes it relatively simple to do other potentially unsafe things like opening unknown, arbitrary, potentially-adversarial PDFs in a safe way within that sandbox.

[2]:  Sometimes this is the best option. According to at least one of my friends who does Red Team work, macOS has gotten sufficiently challenging to gain persistence on that she just phishes Mac users again by default rather than bothering.

[3]:  If you followed the default installation instructions for WordPress, circa 2012, they would tell you to configure your site so that WordPress could write to its own program directories.

This was great for usability, because it allowed users to upgrade to new versions by clicking a button in the WordPress web UI rather than futzing at the command-line, and on some level theoretically that was good security, because most compromises happen due to already-patched vulnerabilities exploited in old, non-upgraded running instances of the software, so making it easier to upgrade is better.

However in practice this meant that any attacker who could cause WordPress to run their own code—and WordPress had a lot of vulnerabilities that enabled attackers to run their own code—had an easy path to write their code to disk in a place where it would get run again even after the user restarted WordPress or rebooted their server.

A better design would have given WordPress only read access to its program directories, and made the updater a separate service, running under a separate user account that had write access to WordPress’s program directories, and which the main WordPress program shared very little data with and had very little control over besides telling it to run an update.

This was impractical at the time given WordPress’s target user community and deployment model, and this is why I still tell people not to run their own WordPress, but to use a commercial hosting service.  (And checking in, not much appears to have changed, sadly.)

[4]: My estimates are based on conversations with a head of security I worked for several years ago and other senior community members over the years, as well as the bounties paid out by the Pwn2Own contest, which serves as a public floor for vulnerability prices.  Real-world attacks almost always require chaining multiple vulnerabilities of the kind discovered and disclosed at Pwn2Own.