The modern cellular network is a marvel of technological advancement that we often take for granted now. With 5G service it’s easy to do plenty of things on-the-go that would have been difficult or impossible even with a broadband connection to a home computer two decades ago. But it’s still reliant on being close to cell towers, which isn’t true for all locations. If you’re traveling off-grid and want to communicate with others, this guide to using Winlink can help you send emails using a ham radio.
While there are a number of ways to access the Winlink email service, this guide looks at a compact, low-power setup using a simple VHF/UHF handheld FM radio with a small sound card called a Digirig. The Digirig acts as a modem for the radio, allowing it to listen to digital signals and pass them to the computer to decode. It can also activate the transmitter on the radio and send the data from the computer out over the airwaves. When an email is posted to the Winlink outbox, the software will automatically send it out to any stations in the area set up as a gateway to the email service.
Like the cellular network, the does rely on having an infrastructure of receiving stations that can send the emails out to the Winlink service on the Internet; since VHF and UHF are much more limited in range than HF this specific setup could be a bit limiting unless there are other ham radio operators within a few miles. This guide also uses VARA, a proprietary protocol, whereas the HF bands have an open source protocol called ARDOP that can be used instead. This isn’t the only thing these Digirig modules can be used for in VHF/UHF, though. They can also be used for other digital modes like JS8Call, FT8, and APRS.
Imagine the Internet had begun its life as a proprietary network from a major software vendor rather than evolved as a distributed network shared by researchers. It’s a future that almost came to pass for consumers in the 1990s when walled gardens such as AOL or the original incarnation of MSN were all the rage, but thankfully the world took the Internet course.
Though there are many continuing threats to Internet freedom we can still mostly use the network our way, but with sadness we note that one piece of Internet freedom may have drawn to a close. [Carlos Fenollosa] has written a lament about how the outlook for anyone running their own mail server now looks bleak.
At its heart is spam, or indeed the heavy-handed measures taken by large email providers to combat it. Spotting and canning spam is computationally expensive, so the easiest way to stop a spammer is to recognize their activity and block it at the network level. Thus a large email provider will instantly block large IP ranges when it detects they hold a spammer, with the collateral damage of also blocking any legitimate email servers in the same range such that their mail just doesn’t get through. Since spam is such a widespread problem, as [Carlos] points out it’s less of a case of if your server has this problem, but when. This functions essentially as something of a racket, in which large email providers have the power to ensure that any email not generated from amongst themselves is unlikely to reach any of the millions of addresses under their care, and the only recourse an operator of a small email domain has is to use the services of one of them.
He has something of a manifesto as to how this problem can be addressed, and we think that it’s important enough that you should take a look. Maintaining email as something beyond the control of large providers is too important not to.
While pundits routinely predict the end of e-mail, we still get a ton of it and we bet you do too. E-mail has been around for a very long time and back in the day, it was pretty high-tech to be able to shoot off a note asking everyone where they wanted to go to lunch. What we had on our computers back then was a lot different, too. Consider that the first e-mail over ARPANET was in 1971. Back then some people had hardcopy terminals. Graphics were unusual and your main storage was probably a fraction of the smallest flash drive you currently have on your desk. No one was sending photographs, videos, or giant PDF files.
Today, things are different. Our computers have gigabytes of RAM and terabytes of storage. We produce and consume richly formatted documents, photographs at high resolutions, and even video. Naturally, we want to share those files with others, yet e-mail has turned up woefully short. Sure, some systems will offer to stash your large file in the cloud and send a link, but e-mailing a multi-megabyte video to your friend across town is more likely to simply fail. Why?
Every five years or so, I think it’s time to review my e-mail flow. (Oh no!) I run my own mail server, and you should too, but this means that I get to figure out managing and searching and archiving and indexing it all by myself. (Yippee!)
And I’ll be honest — sometimes I’m a bit of a luddite. I actually, literally have been using Mutt, or its derivative NeoMutt for maybe fifteen years, after a decade or so of mouse-intensive graphical mail readers. If e-mail is about typing words, and maybe attaching the occasional image, nothing beats a straight-up text interface. But what a lot of these simple mail clients lack is good search. So I decided to take that seriously.
Notmuch is essentially an e-mail database. It’s an e-mail searcher, tagger, and indexer, but it’s not much else. The nice thing is that it’s brutally fast. Searches and extraction of tagged subsets are faster than sending the same data back and forth to the Big G, and I have a ton more flexibility. It’s awesome. Of course good ol’ Mutt can work with Notmuch. Everything can. It’s Linux/UNIX. Continue reading “Wreck Your Mail Before You Check Your Mail”→
All of us have seen our share of phishing emails, but there are a lot more that get caught by secure email gateways and client filters. Threat actors are constantly coming up with new ways to get past these virtual gatekeepers. [BleepingComputer] investigated a new phishing attack that used some old tricks by hiding the malicious script tags as morse code.
The phishing attack targets Microsoft account login credentials with an HTML page posing as an Excel invoice. When opened, it asks the user to re-enter their credentials before viewing the document. Some external scripts are required to render the fake invoice and login window but would be detected if the links were included normally. Instead, the actor encoded the script links using dots and dashes, for example, “.-” equals “a”. A simple function (creatively named “decodeMorse”) is used to decode and inject the scripts when it runs in the victim’s browser.
Of course, this sort of attack is easy to avoid with the basic precautions we are all familiar with, like not opening suspicious attachments and carefully inspecting URLs. The code used in this attack is simple enough to be used in a tutorial on JavaScript arrays, but it was good enough to slip past a few large company’s filters.
Despite the popularity of social media, for communication that actually matters, e-mail reigns supreme. Crucial to the smooth operation of businesses worldwide, it’s prized for its reliability. Google is one of the world’s largest e-mail providers, both with its consumer-targeted Gmail product as well as G Suite for business customers [Jeffrey Paul] is a user of the latter, and was surprised to find that URLs in incoming emails were being modified by the service when fetched via the Internet Message Access Protocol (IMAP) used by external email readers.
This change appears to make it impossible for IMAP users to see the original email without logging into the web interface, it breaks verification of the cryptographic signatures, and it came as a surprise.
Security Matters
A test email sent to verify the edits made by Google’s servers. Top, the original email, bottom, what was received.
For a subset of users, it appears Google is modifying URLs in the body of emails to instead go through their own link-checking and redirect service. This involves actually editing the body of the email before it reaches the user. This means that even those using external clients to fetch email over IMAP are affected, with no way to access the original raw email they were sent.
The security implications are serious enough that many doubted the initial story, suspecting that the editing was only happening within the Gmail app or through the web client. However, a source claiming to work for Google confirmed that the new feature is being rolled out to G Suite customers, and can be switched off if so desired. Reaching out to Google for comment, we were directed to their help page on the topic.
The stated aim is to prevent phishing, with Google’s redirect service including a link checker to warn users who are traveling to potentially dangerous sites. For many though, this explanation doesn’t pass muster. Forcing users to head to a Google server to view the original URL they were sent is to many an egregious breach of privacy, and a security concern to boot. It allows the search giant to further extend its tendrils of click tracking into even private email conversations. For some, the implications are worse. Cryptographically signed messages, such as those using PGP or GPG, are broken by the tool; as the content of the email body is modified in the process, the message no longer checks out with respect to the original signature. Of course, this is the value of signing your messages — it becomes much easier to detect such alterations between what was sent and what was received.
Inadequate Disclosure
Understandably, many were up in arms that the company would implement such a measure with no consultation or warning ahead of time. The content of an email is sacrosanct, in many respects, and tampering with it in any form will always be condemned by the security conscious. If the feature is a choice for the user, and can be turned off at will, then it’s a useful tool for those that want it. But this discovery was a surprise to many, making it hard to believe it was adequately disclosed before roll-out. The question unfolded in the FAQ screenshot above hints at this being part of Google’s A/B test and not applied to all accounts. Features being tested on your email account should be disclosed yet they are not.
Protecting innocent users against phishing attacks is a laudable aim, and we can imagine many business owners enabling such a feature to avoid phishing attacks. It’s another case where privacy is willingly traded for the idea of security. While the uproar is limited due to the specific nature of the implementation thus far, we would expect further desertion of Google’s email services by the tech savvy if such practices were to spread to the mainstream Gmail product. Regardless of what happens next, it’s important to remember that the email you read may not be the one you were sent, and act accordingly.
Update 30/10/2020: It has since come to light that for G Suite users with Advanced Protection enabled, it may not be possible to disable this feature at all.
There have been many news stories lately about companies misusing your data, including your e-mails. What’s more, these giant repositories of data are favorite targets for hackers. Even if you trust the big corporations, you are also betting on their security. Criptext claims they have (possibly) the most private e-mail service ever. It uses the open Signal protocol and stores private keys and encrypted mail only on your device. All the applications to access your mail are open source, so presumably, someone would eventually spot any backdoors or open holes.
At the moment the service is free and the company reports that even when a paid offering is ready, there will still be a free tier. Of course, you can send and receive normal e-mail, too. You can also use a passphrase you send to someone else (presumably not by e-mail) so they can read an encrypted message.
