Privacy and SecurityIn this open series, you can contribute shows that are on the topic of Privacy and Security
TLS 1.3 was just adopted, and it provides improved security for all Web communications. We take a look at what the protocol says and look at the controversies around its adoption. http://www.zwilnik.com/?page_id=980
Diffie-Hellman Key Exchange is used in a security technique called Forward Secrecy that aims to secure your encrypted communications from future decryption by unauthorized entities. While it does provide additional security it is not absolutely bullet-proof. So while we explain how it works and provides security, we will also discuss how it can go wrong. For more go to http://www.zwilnik.com/?page_id=957
Diffie-Hellman Key Exchange is based on work initially done by Ralph Merkle, and remains one of the key developments in secure communication over the Internet. In this episode I try to explain just how this works, with an example of a calculated key exchange.
For more go to http://www.zwilnik.com/?page_id=955
I had the opportunity to present a talk on SSL Certificates at our local LUG, the Washtenaw Linux Users Group, which uses some material from a previous HPR episode, but may be of interest to our listeners nonetheless. Because this was a lengthy presentation I have divided it into sections. This is the second section which will explore some of the problems that we have with SSL Certificates, and how we might address those problems. The first section contains our description of how SSL Certificates work.
For more go to http://www.zwilnik.com/?page_id=686
I had the opportunity to present a talk on SSL Certificates at our local LUG, the Washtenaw Linux Users Group, which uses some material from a previous HPR episode, but may be of interest to our listeners nonetheless. Because this was a lengthy presentation I have divided it into sections. This first section explains how SSL Certificates work, and the second one will explore some of the problems that we have with SSL Certificates, and how we might address those problems. For more go to http://www.zwilnik.com/?page_id=655
I had the opportunity to present a talk on the LastPass intrusion at our local LUG, the Washtenaw Linux Users Group, which expanded on a previous HPR episode and added some additional material that I think might be of interest to our listeners. I still stand by my claim that LastPass was not seriously affected by the intrusion and is still an excellent security solution for most computer users. For more go to http://www.zwilnik.com/?page_id=841
In Episode 1900, Ahuka advised you not to expose the ssh service to the Internet on the default port 22, there we agree. This is called "Security Through Obscurity". Whenever possible, server functions exposed to the Internet should be on non-default port numbers (the exception being HTTP on a public web server). I disagree however, in Ahuka's method of changing the port. He said you should change the port on the server itself:
Open /etc/ssh/sshd_config file and look for line Port 22 and change line to Port 2222. Restart sshd server. systemctl restart sshd
Sshd is running on a non-standard port, connection attempts to the system will fail. You need to connect using following command:
$ ssh -p 2222 user@your-ip OR $ ssh -p 2222 firstname.lastname@example.org
This could make sense if you manage a business or school network, where you have numerous users within your network with whom you share varying levels of trust. Still, I don't think anyone who can brute force your shh logon or shared keys would be stymied by a simple change of ports. But Ahuka also mentioned home networks, and I think we would rather keep things simple. I would humbly suggest keep ssh servers set to port 22 internally, and using a technology called "port forwarding" available on most consumer routers. Port forwarding is simply an administrator configured table that redirects incoming traffic on one IP port to a specific internal IP address and IP port on your internal network. In fact, unless you have only one PC connected directly to you ISP with no router or firewall, you will still need to setup port forwarding to tell the router which machine on your network the for which incoming communication is intended.
In other words, let's say you've enabled ssh on port 40001 of a machine with an internal address of 192.168.1.5. You try to login remotely via ssh on port 40001 using the external IP assigned to you by your ISP (which is taken from a range assigned to them by the IANA). The external IP of your router should be displayed on your router's status page, or you could type "what is my IP" into Google. Instead of an IP in the range 192.168.x.y, like you are probably using internally, your external address will be in the Class A or B range, for instance 18.104.22.168.
So let's say you have ssh server running on port 40001 on a machine with IP adddress 192.168.1.5 on your home network. Your server has an external address of 22.214.171.124. You are at work or on vaction or whatever and you want to ssh into that machine on your home network, i.e,
ssh -p 40001 email@example.com
Unless the router itself supports ssh server (entirely possible with third party Linux based firmwares like Open-WRT and DD-WRT), if you haven't configured port fowarding, the router won't have any idea what to do with an incoming request on port 40001. You need to set up your port forwarding table in your router (don't worry, it's all point and click). IP forwarding may be under Advanced, in the menus, or Security, or Firewall, or a combination of the above.
You will be asked to enter the external port number (in our example, 40001), TCP or UDP or both (in our case, ssh is both, so you may have to create two separate entries), the internal IP address (in our example 192.168.1.5) and the internal port number (if you changed it internally as Ahuka recommended, in our example 40001, but, and this is the whole point of this podcast, you are going to have to set up port forwarding anyway, so why change the port number locally in the first place? If the terms TCP (Transport Control Protocol) and UDP (User Data Protocol) are unfamiliar to you, the difference can easily be explained. Using TCP, the computer transmitting data stops every few packets (I think the default is three, but don't hold me to it) until it gets an acknowledgment from the receiver that the packets were successfully received, then the sender continues. With UDP, the sender blurts out the whole transmission without caring whether the receiver go it or not.
Wikipedia has a great article on official and unofficial standardized port numbers. Once you get into five digits, conflicts to already assigned ports are rare, but it's still best to consult the Wiki. The higher numbers are generally not officially assigned, some particular software product is just "squatting" on the number. In fact, using the port number for a technology you are certain will never be used on your network may further obfuscate the service for which you are actually using it. You may think port 40001 is surely high enough to be free of conflict, but the Wiki says 40000 is used by "SafetyNET p Real-time Industrial Ethernet protocol".
Another advantage of port redirection is you could use a different external port number with every host on your network, i.e., 40001 redirects to you server, 40002 redirects to your desktop, 40003 redirects to the old laptop in the kid's room, etc. Personally, I'd only have port redirection into a single machine that is connected persistently (like a server), and the ssh from it into other hosts on the network (yes, this would be a connection of at least three nested shells). You can even run graphical programs over ssh with the -X argument, but I'm leaving that on for later discussion. Of course, we will loose that functionality when we move from x-server to Wayland, so if you need a GUI you may have to investigate technologies like VNC or VPN.
Of course, everything depends on having a static IP locally on the ssh server (either set on host itself or manual assignment of IP on the router, if possible). You either need a static external address on the WAN (i.e., external address as seen from the Internet) side or employ a domain forwarding service. Also keep in mind, once we get Ivp6, everything above goes out the window.
When you first try to login to a remote server you need to authenticate yourself, which means you have to demonstrate that you have rights to be on that server. You can do this in several ways:
- Password You authenticate to the server by typing in your password. This is easy because you can generally remember your password, and it means you can easily login from any computer with that knowledge. This is still the most common authentication mechanism for SSH. It is also the least secure.
- Public Key This is much more secure. It involves the creation of a key pair, of course. It is possible to use a key pair generated by PGP or GPG in the most current versions (version 2.0.13 introduced support for this). But there is a long established method using the Unix program ssh-keygen. This is very similar to generating a key pair as we discussed earlier. You run the program ssh-keygen, harvest some entropy, generate a passphrase to protect it, and so on.
For more go to http://www.zwilnik.com/?page_id=733
So as we saw in the introductory tutorial, SSH uses the Client-Server model. Now, technically a server is just the machine you are connecting to, and there is no reason in principle that it could not be another desktop, a laptop, or even a telephone if it has the appropriate software. and in the previous tutorial we showed how you can easily install and set up an ssh server on your home network using another computer or a Raspberry Pi so that you can experiment with these commands. The model really reduces to you as the client, and the other machine as the server. As with all Internet connections there are standards and protocols involved. The original Telnet communicated over TCP through port 23. Because SSH was conceived as a replacement, it used the same TCP protocols, and was assigned the adjacent port number of 22. For more go to http://www.zwilnik.com/?page_id=726
My LastPass Alternative
- Password Database: KeePass http://keepass.info/ KeePass client is in the fedora repos.
Save file to a location that will be synced between devices. Im my case Owncloud. Desktop Client syncs available for Linux, Windows and Mac. Mobile clients for Android, IOS, and even blackberry. Syncing note: I do not launch the desktop client on login. This allows the owncloud client to sync files before launching keepass. Also, I exit keypass before logging out for the same reason.
For integration with browser, there are
- Firefox: Passifox https://addons.mozilla.org/en-US/firefox/addon/passifox/
- Chrome: chromeIPass https://chrome.google.com/webstore/detail/chromeipass/ompiailgknfdndiefoaoiligalphfdae?hl=en
- Android: https://f-droid.org/repository/browse/?fdfilter=keepass&fdid=com.android.keepass
And finally when on machines I don't control:
- Remote Access: Browser Pass https://bitbucket.org/namn/browsepass/
On same server with ownlcloud, can open files
A walk through of how to use diceware (http://world.std.com/~reinhold/diceware.html) to create a passphrase and update your GPG key to use it.
The best way to get familiarity with the concepts we will discuss is by experimentation. I think that it is becoming more common these days for people to own more than one computer and set them up in a network. And with cheap computers like Raspberry Pi it is really easy to get started. In this tutorial I want to discuss how you can set up such a server for your experiments in ssh. I encourage you to do this even though I dont intend this series to focus on server administration. The idea is that by practising these these techniques behind a good firewall you can get some familiarity with them before you get out on the Internet where it matters. For most Linux users, at least, installing and setting up a server is really simple, and you can do it minutes. For more go to http://www.zwilnik.com/?page_id=847
In 1995 there was a password-sniffing attack on the network of the University of Helsinki in Finland, and this lead a researcher there, Tatu Ylönen, to create the first SSH implementation. SSH is an acronym for Secure Shell, and expresses the idea that you can securely log in and get a shell on a remote server. This was initially released as free software, but in later versions he took it proprietary. But the developers at OpenBSD decided that a free software implementation was needed, and they created OpenSSH, which is the basis for most implementations today. For more go to http://www.zwilnik.com/?page_id=722
How to Hide a Password Using a Password Card
It's okay to write your password down and keep it in your wallet, but it's best to try to hide it as well. Here's how to keep your password secure and handy at the same time by embedding it in a password card.
Generate a fancy symbol-and-color-coded password card at passwordcard.org: http://www.passwordcard.org/en. Follow the directions there on how to use it best.
Make your own. Use the password generation package
pwgenon Linux to generate a whole bunch of random passwords. In the following example, the
-sflag tells it you want secure passwords that are generated randomly, not suitable for human memory. The
-yflag tells it to include special characters, and
24indicates how many characters each password should contain.pwgen -sy 24
Then either use one of the passwords that was generated from this command or embed your own existing password somewhere inside the giant block of gibberish such that only you will know where your password begins and ends. You can put a copy of this in your wallet.4b$0<k=#;?MJ^K:Uw\6zmP5s
If you want extra security make two columns or increase the character count.ra;aH5v"}2lF()\;K0f-G;YT 3XGq>wQ6")UvSU#NpYfr,M(h
On June 15, LastPass disclosed that it had been hacked, and I think by now just about everyone has heard about it. I know I received questions because I have recommended LastPass often, and my advice has been to stay with them. What I want to do now is explain exactly why this was not quite the big deal it was made out to be in some quarters, and that anyone telling you to stop using password vaults is only asking you to lower your own security.
For more go to http://www.zwilnik.com/?page_id=841
Previously we looked at the issues around TrueCrypt and Heartbleed, and noted that a fundamental problem was that technologies we rely on to be safe are often developed and maintained by volunteers or people on a shoestring budget. There is now more news worth looking at in this respect, so it is time for an update. For more go to http://www.zwilnik.com/?page_id=825
HTTPS Everywhere will automatically direct your browser to a secure https version of sites you visit, if available. Great for security (obviously).
Adblock Edge is a great ad blocker. It blocks all ads no matter how obtrusive they are. Does not contain hidden white-list like more popular ad blocker: Adblock Plus.
Last time we looked at some basics about how TLS and SSL work, and saw that this is basically an application of the same technology used to encrypt e-mails. But we also noted that there are some problems with this approach. We need to recognize that in security there is never a permanent solution, and that vulnerabilities are constantly being discovered, and ideally then being fixed. Some of these may involve highly technical issues about cryptographic methods, but I think the largest category of issues is about the processes around the use of certificates. For more go to http://www.zwilnik.com/?page_id=686
Digital Signatures are something that is very important in understanding security on the Internet. While we have seen it in the context of personal e-mail, the applications are much broader, in particular to the use of certificates to establish communication.
Recall from our discussion of e-mail that there are two things you can do with an e-mail using PGP or GPG. First is you can encrypt the message, which you do using the public key of the recipient, and then they can decrypt the message using their private key. The other was putting a digital signature on a message. But how does that work? - For more go to http://www.zwilnik.com/?page_id=655
Previously we looked at Public Key encryption, which is also called Asymmetric Encryption because it uses two different keys for the encryption and decryption. This allows us to solve one of the biggest problems in secure encrypted communication, which is key distribution. Because the public key can be freely distributed, you dont need to maintain security around the process of distributing keys. Symmetric encryption, on the other hand, relies on a shared key that is used for both encryption and decryption. An example of this is the one-time pad, where you printed up a pad of paper that contained various keys, and each one was used only once. As long as no one can get the key, it is unbreakable, but the big weakness was key distribution. How do you get the one-time pad into the hands of your correspondent? And you would need to do this with separate one-time pads for each person you needed to communicate with. These are the kinds of problems that made asymmetric encryption so popular. Finally, symmetric key crypto cannot be used to reliably create a digital signature. The reason should be clear. If I have the same secret key you used to sign a message, I can alter the message, use the shared secret key myself, and claim you sent it. - For more go to http://www.zwilnik.com/?page_id=650
Right now for most of us the key to any security in our online life is the degree of entropy in our passwords. So what is entropy, and how does it affect our passwords?
Entropy is in general the degree of randomness or disorder in any given system. Sometimes it is very easy to assess, such as a password of 1234, which all too many people use. Because it is a simple sequence, there is no real randomness at all, and would be quickly guessed. And as we saw in the last tutorial, such passwords are quickly discovered in a dictionary attack. There are things you can do to make it less likely that your password will be cracked and used against you. - For more go to http://www.zwilnik.com/?page_id=530
Today, the most common way of providing security in giving access to data or systems is through the use of passwords. Practically every online site now expects you to create an account with a password, which will let you post comments, order products, conduct business, or just post to social media. The implication is that insisting on passwords provides some level of security. Now, following on our last tutorial we should ask a few questions about just how effective this measure is, since someone posting in your name to Twitter is significantly different from someone accessing your bank account. And since the assets being protected are very different, it would be reasonable to approach the problem of security somewhat differently in these cases. But given the ubiquity of passwords as the authentication for online accounts, we need to look at the security involved. Note that I am approaching this from the standpoint of the owner of the site in question for this tutorial, and will follow up with a look at your own role in this.
For more go to http://www.zwilnik.com/?page_id=640
Back in 2001 there was a certain incident on September 11 that lead many people to go OMG! We are doomed! We must increase security! Do whatever it takes! And the NSA was happy to oblige. And on 7/7/05 an attack in London added to the frenzy. I think it is fair to say that these security agencies felt they were given a mandate to do anything as long as it stops the attacks, and thus was the overwhelming attack on privacy moved to a whole level higher. To be clear, security agencies are always pushing the limits, it is in their DNA. And politicians have learned that you never lose votes by insisting on stronger security and appearing tough. - For more go to http://www.zwilnik.com/?page_id=577
We have looked at e-mail encryption on both Thunderbird and G-Mail, and that is good, but in 2014 a lot of people use mobile phones and tablets for their e-mail. So it makes sense to look at how we can do this. The solution I am going explore here involves two components, the K-9 Android mail client, and APG, the Android Privacy Guard. I am going to stick to what I know, so if you are looking for help with iPhone or iPad, the best I can do is suggest that you try a Google search. On Android, while many people use Gmail, K-9 is a very popular client for people looking for a more traditional POP3 or IMAP client to handle their e-mail needs. So this should be a good solution for many people. As regards APG, I am not aware that anyone has done an audit of this program. It seems to be the most widely recommended, and is probably OK, but I am making no larger claims for it. - For more go to http://www.zwilnik.com/?page_id=602
Two recent events have shed light on some fundamental issues in getting security in Open Source projects. One of them is a serious bug referred to as "Heartbleed", and the other is the first part of a security audit of the TrueCrypt encryption program. By looking at both of these together and doing a Lessons Learned we can draw some conclusions about what is needed to have security in Open Source projects.
This is a recording of a talk I gave at my local Linux Users Group, the Washtenaw Linux Users Group, or LUGWASH. In this talk I cover some of the theory of encryption, how to generate keys, and using this with Thunderbird, with Gmail, and on an Android phone.
One of the issues in using public key encryption is ensuring you know who you are communicating with, and that you have correctly matched the owner to the key. Otherwise, your communication could be intercepted and decrypted by a third-party. The way we solve this problem is with key signing, which is often done at key signing parties. We discuss all this with Tony Bemus of the Sunday Morning Linux Review.
This guide will walk you through setting up an OpenVPN server as well as a client.
OpenVPN Server Setup
Here is how to install OpenVPN on Centos6. Other RedHat derivatives should be similar.
wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm rpm -Uvh epel-release-6-8.noarch.rpm yum install openvpn -y
Here is how to install OpenVPN on a Debian server. Other Debian derivatives should be similar.
apt-get install openvpn
After the server is installed, the server certificate authority and keys must be generated. This will be followed by the client keys, and then the server configuration file.
Copy the easy-rsa scripts into /etc/openvpn
cp -rf /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa # on Debiancp -rf /usr/share/openvpn/easy-rsa/2.0/* /etc/openvpn/easy-rsa # on Centos6
Set Environmental variables
cd /etc/openvpn/easy-rsa vim vars
Change the following variables to meet your needs. These are used for your convenience. They will be used as the defaults during the interactive key generation session to set the keys attributes.
export KEY_COUNTRY="US" export KEY_PROVINCE="CA" export KEY_CITY="SanFrancisco" export KEY_ORG="Fort-Funston" export KEY_EMAIL="firstname.lastname@example.org"
Source the variables to the current shell
Create certificate authority
./clean-all ./build-ca ./build-dh
Create keys for the server and clients
./build-key-server server ./build-key client1 ./build-key client2
Setup the server configuration file
cd /etc/openvpn gunzip /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz # on Debian vim /etc/openvpn/server.conf
port 1194 proto udp dev tun ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/server.crt key /etc/openvpn/easy-rsa/keys/server.key dh /etc/openvpn/easy-rsa/keys/dh2048.pem server 10.10.42.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-config-dir ccd route 10.10.42.0 255.255.255.0 client-to-client keepalive 10 120 cipher AES-256-CBC # AES comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3
Restart VPN Service
service openvpn restart
If the service fails to start, try starting openVPN manually. The resulting errors will allow you to see what item in the configuration file is incorrect.
Once you are able to get openVPN to start without error, kill it and restart it using the service command above. You can verify that the vpn is successfully running by looking at the configured interfaces using the following command.
You should now see an entry like the following:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.10.42.1 P-t-P:10.10.42.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:622255 errors:0 dropped:0 overruns:0 frame:0 TX packets:986993 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:40649523 (38.7 MiB) TX bytes:1344026670 (1.2 GiB)
OpenVPN Client Setup
The installation of OpenVPN for linux is the same as described above for the server. For Windows, Download and run the OpenVPN installer from the OpenVPN Community Downloads.
NOTE: On Windows, User Account Control (UAC) must be turned off in order to allow OpenVPN to execute the necessary network commands to bring up the VPN. Open Start > Control Panel > User Accounts and Family Safety > User Accounts > Change User Account Control Settings. Set to Never Notify, click OK, and reboot the machine.
Client Configuration file
For linux, the client config file would go in `/etc/openvpn` just like the server config. We will name it `client.conf` to clarify that the device is being configured as an OpenVPN client. On Windows, the keys and client config files go in the `C:\Program Files (x86)\OpenVPN\config`. The config file has to have an `.ovpn` suffix.
client dev tun proto udp remote myvpn.example.org 1194 resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca /etc/openvpn/keys/ca.crt # on Windows, the format is: # ca "C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt" # Windows may also change the file suffix on the crt files to cer. # So, If Windows complains that it cannot find the file, # examine its properties to verify the suffix. # The logs are stored at C:\\Program Files (x86)\\OpenVPN\\log cert /etc/openvpn/keys/client1.crt key /etc/openvpn/keys/client1.key ns-cert-type server cipher AES-256-CBC comp-lzo verb 3
Copy client key and server ca files onto client
scp ca.crt user@client1:.openvpn/ scp client1.crt user@client1:.openvpn/ scp client1.key user@client1:.openvpn/
On the server create the ccd directory to assign static addresses to clients.
For each device, add a file with the CN name of the key. In that file, you will indicate the static address to be used and the server IP For linux, the server IP will be the VPN address of your VPN server. On Windows, the VPN client will set up a local TAP interface that must be used as the server IP. See the OpenVPN docs for available client and TAP server IP pairs.
cat /etc/openvpn/ccd/linux-client ifconfig-push 10.10.42.10 10.10.42.1 cat /etc/openvpn/ccd/windows-client ifconfig-push 10.10.42.13 10.10.42.14
The "Heartbleed" vulnerability in OpenSSL (CVE-2014-0160) is a bounds checking error in the heartbeat implementation that could return up to 64K of private data to the client. This can lead to server certificate private keys, session cookies, clear text passwords, or other sensitive data being leaked from the server to the client. This vulnerability exists in OpenSSL versions 1.0.1 through 1.0.1f and 1.0.2 beta.
It is important for server administrators to update OpenSSL as soon as possible and take steps to secure any private data which may have been leaked. This may include updating server certificates and revoking certificates that may have been compromised.
Users should ensure that web sites they use have been secured and should update passwords or other authentication information.
Last time we looked at how you can use GPG and Enigmail to digitally sign or encrypt messages in Thunderbird. But today many people use web-based mail, and one of the most popular is Googles Gmail. Others include Outlook.com and Yahoo, but using any of them is pretty similar. So since I have a Gmail account handy, I will use that to demonstrate encryption in web mail accounts.
The important thing you must keep in mind is that this relies on you using your GPG keys to either sign or encrypt the message before it leaves your computer, what Steve Gibson calls Pre-Interent Encryption, or PIE. The flaw in what Lavabit did (discussed in previous lesson) was to use keys that the mail provider controlled, and these keys could be (and were) demanded by the the government.. If you use your own GPG keys that you control, no provider (Google, in this case) is even capable of giving anything to the government other than a blob of random nonsense.
To do this, I will use an extension for Googles Chrome Browser called Mailvelope. This is also available for Firefox, but in my case I use Chrome to access my Gmail account., so using a Chrome extension makes sense for me. The first thing to do is go to the Chrome store, search for Mailvelope, and install it.
For the remainder of the show notes please see http://www.zwilnik.com/?page_id=546
encrypting: $ openssl bf -e < my_file > my_file.bf decrypting: $ openssl bf -d < my_file.bf > my_file
Now it is time to take a look at practical uses of encryption, and the number one use is for e-mail. Encrypted communication via e-mail is very desirable if you want to keep a secret. In the U.S. the current legal precedents say that any e-mail left on a server is not protected since you would have no expectation of privacy. This precedent was set many years ago when POP3 was the standard for all e-mail and people did not usually leave e-mail on a server. These days, many people use web-based e-mail or use a newer standard called IMAP which by default stores everything on the server. Perhaps you are one of these people, and thought that you had a right to expect privacy, but in the U.S. you dont, and I would expect that in many other countries the situation is no better.
There have been attempts to provide encrypted e-mail service from a service provider, but the problem here is that the provider usually has to have to the key in order to encrypt the e-mail, and if they have the key they can be compelled to give it up. Recently in the U.S. there was a case involving Ladar Levison who ran such a service called Lavabit. Lavabit encrypted mail in transit using TLS encryption, and he had the keys. When his service was used by Edward Snowden, the government came to get the keys. Now, Levison would have given them the key for Snowdens e-mail if he had been served a warrant, as he always made clear to his customers that he would obey proper legal demands. But in this case the government demanded that he turn over all of the keys for all his customers, and this was too far for Levison. He shut down his service rather than cooperate, and is a bit of a hero for that. But it illustrates that you are at the mercy of the service provider. If the government made this demand to Lavabit, you are safe in presuming they had made the same demand to other providers, and that they all cooperated with the government and said nothing to their customers. So it would be mistake to rely on 3rd party mail service providers to give you privacy. You need to control it yourself. But of course, after the last few lessons you know how to do that, and have your secure keys created. You just need to put them to use.
For the remainder of the show notes please see http://www.zwilnik.com/?page_id=547
I attended FOSDEM 2014 in Brussels, Belgium. During the conference there was a key signing event which I attended. These are my impressions of the process and the follow-up.
In this episode, deepgeek suggests that adding and old, and perhaps laughable by modern standards, device to your mobile lifestyle. Deepgeek reveals that said device is the pager, but he eventually gives good reasons for doing so.
The primary reason is that the paging company does not know where you are, so they can't tell "the man" where you are. Other reasons are redundancy and trouble interpreting audio. But in the end, you find out why first responders and medical and fire personal still use these devices, and how you, as a privacy lover, may reap benefits from using this technology also.
Some links mentioned in case you want to follow them...
Duck Duck Go search on locational privacy https://duckduckgo.com?q=locational+privacy
"privacy is dead" audio
USA's two remaining paging companies
don't forget to check out resellers for deals, like "free pager with one year prepaid
A good sms via email webpage
This is the third in our Security and Privacy series, and explains how you can generate keys on the command line in Linux using GPG.
This article appears on my web site at http://www.zwilnik.com/?page_id=456.
Remember to support free software!
In this episode of our Privacy and Security series we look at the fundamentals of encryption and how it has developed over the centuries. We will also develop a basic idea of the current asymmetric public key cryptography.
Some useful sites
This article appears on my web site at http://www.zwilnik.com/.
Remember to support free software!
In this episode of our Privacy and Security series we look at two issues. The first is why we need Privacy, and the second is whether it is practical in the 21st century. I hope to show that we do need it, and that it is both practical and surprisingly easy to do some simple things to obtain it.
Some useful sites
- Room 641A and the NSA
- Cory Doctorow's Books
- The Command Line Podcast
- The Code Book
- The Puzzle Palace
- Security Now
- Hak 5 video podcast
- Bruce Schneier
- Schneier on Security
- Bruce Schneier's Crypto-Gram Newsletter
- SANS Institute - http://www.sans.org
- Krebs on Security - http://krebsonsecurity.com/
This article appears on my web site at http://www.zwilnik.com/.
Remember to support free software!
Drake continues his series of Misunderstanding privacy.
Daniel J. Solove