Expat-IT Tech Bits

Home

Contact

Links

Search this site:

Categories:

/ (287)
  Admin/ (122)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (6)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (30)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)

Archives:

  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    PyBlosxom

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Sat, 16 Jan 2010


    /Security/e-mail: Setting Up PGP E-mail Encryption

    Finally someone has agreed to help me play with PGP e-mail encryption!! So here are my notes:

    In my claws-mail e-mail client, I had to install a plugin (a separate package in Debian) called claws-mail-pgpmime. After restarting, there appeared a "GPG" tab in my per-account e-mail preferences, where I clicked on the "Generate a new key pair" button. (claws-mail apparently does all the necessary pgp stuff under the hood, including adding the new keys to my private key ring....) In the same tab, I also selected the "select key by your e-mail address", which seemed logical. And then in the "Privacy" tab do not forget to select when you want your key sent, and under what circumstances e-mail is supposed to be encrypted. (And I was delighted to see a "Save sent encrypted messages as plain text option", since I have an encrypted home directory anyway.)

    (Note that this FAQ[1] warns that some spammers harvest e-mail address off of the public key servers, so if you intend to publish your key to such a server, choose an e-mail address with good spam filtering....)

    Now for the fun command line stuff....

    PGP can only work if both ends of the communication have one another's public keys, and from what I can tell, the standard way to do that is via the world-wide network of public key servers. For instance, after adding:

    keyserver keyserver.ubuntu.com

    to ~/.gnupg/options, if I open an e-mail signed with a pgp-signature attachment, I can then click on the key icon to the right of my claws-mail message pane and see the prompt:

    "This key is not in your keyring. Do you want Claws Mail to try and import it from a keyserver?

    Of course(!?) this does not work in China because all the keyservers seem to be blocked, so I have to do it through a proxy server as follows:

    proxychains gpg --no-tty --recv-keys A1295TE1D75F5533

    And now claws-mail can verify the signature as "correct". And now

    gpg --list-keys

    will show all the keys on my private key ring, including the one I just imported. That is how I get my friend's public key.

    Per this fine howto[2], I can broadcast my own key to the world thusly:

    gpg --send-keys --keyserver keyserver.ubuntu.com 6D79E522

    where the code at the end of the line is obtainable from the "gpg --list-keys" listing.

    Note that it is also possible to share public keys by exporting them to a file as follows:

    gpg --export -a 6D79E522 > mykey.asc

    and e-mailing the file. Once both ends are supplied with the other's public key, encryption should be trivial.

    [1] http://pgp.mit.edu/faq.html
    [2] https://help.ubuntu.com/community/GnuPrivacyGuardHowto

    posted at: 08:29 | path: /Security/e-mail | permanent link to this entry

    Wed, 25 Nov 2009


    /Security/e-mail: Basic E-mail Security

    (For those who feel the need to send passwords, credit card numbers, Social Security numbers, and various other sensitive information via e-mail.)

    I am going to talk about the network aspect of e-mail security, and therefore will address points 1 to 5 in the diagram below. First, a little very basic knowledge about what happens to your e-mail when it passes through a network:

    When you send an e-mail, to state the obvious, there is no direct electrical connection between your computer and the computer of your recipient. In fact, as it passes between your computers, the e-mail not only passes through wires, but "hops" its way through many (conceivably many, many) routers and switches. Every time the e-mail passes through a router or switch, whomever controls that router or switch can VERY EASILY capture the digital contents of the e-mail if it is not encrypted. If you are sitting in a coffee shop using an open access point, for instance, the person next to you may be recording your e-mail during its very first hop from wireless card to wireless router. And the owner of the shop could conceivably have software running in the wireless router doing the same.

    Summary of rules for secure e-mail communications:

    1. Sender and Receiver should use the same e-mail server.
    2. Only use https, pop3s, imaps (encrypted connections) to your e-mail service.
    3. Use a small security-oriented e-mail service or a personal e-mail server.

              (1)       (2)        (3)           (4)        (5)
    
                     ----------             -----------
                    |          |           |           |
    Sender =========| Sending  |-----------| Receiving |========== Recipient
                    | Server   |           | Server    |
                    |          |           |           |
                     ----------             -----------
    

    (3) So, by the numbers: for various technical and historical reasons, segment (3) above between the two servers is virtually always unencrypted. It is not strictly true, but for simplicity at the moment lets say that for the case of a simple unencrypted e-mail, YOU CAN NEVER HAVE A SECURE COMMUNICATION IF SENDER AND RECEIVER ARE USING DIFFERENT E-MAIL SERVERS. Ie. if I us Yahoo and you use Gmail, it does not matter what else we do, when passing from the Yahoo servers to the Gmail servers, the e-mail is exposed to snooping.

    Thus Rule 'a' above. If (2) and (4) are the same server, we eliminate all problems with segment (3). For Rule 'c', choose a small service with an emphasis on privacy and security. The bigger the company, the more employees who have potential access to your e-mail. (For the biggest of the free public e-mail providers, this is probably at least hundreds of people, and maybe thousands.) Best of all, use an e-mail server under the personal control of either sender or receiver (ZERO employees who have access to your e-mail).

    (1)(5) To satisfy Rule 'b', only use an e-mail service that provides encrypted connections to the server:

    Finally, a brief mention of something that should see more use, at least by technical people: make all of the above irrelevant by having both sender and receiver use an e-mail client with GPG[1] encryption configured and enabled. After sender and receiver exchange public encryption keys for two specific e-mail addresses, all future e-mails between those two e-mail addresses are encrypted from the moment they leave the sender's e-mail client until the moment they are received by the recipient's e-mail client. If encryption is not desired for any particular (or even most) communications simply use a different e-mail address then the one configured for encryption. A little effort is involved on both ends for setup, but this is by far the best solution. Most desktop e-mail clients have this capability built-in, it basically just has to be turned on. Webmail users, particularly of gmail, may find the Firefox FireGPG[2] plugin to be useful.

    And if you should choose to ignore all of the above advice and send a password, credit card number, or other personal information via insecure e-mail, you would be advised to not include certain important key words in your e-mail. You might think, for instance, that there is such a vast amount of e-mail passing through an internet switch such that no one will ever notice your insignificant little e-mail. But what if they are filtering the traffic for key words, such as "password" or "credit card"? Suddenly your "insignificant" e-mail containing the word "password" becomes a part of a much shorter list of interesting (to a hacker) e-mails.

    Further reading: [3]

    [1] http://gnupg.org/
    [2] http://getfiregpg.org/
    [3] http://www.sovereignman.com/personal-privacy/how-to-send-secure-email/

    posted at: 00:23 | path: /Security/e-mail | permanent link to this entry

    Sat, 14 Nov 2009


    /Security/e-mail: lockbin.com Has a Reasonable Solution for E-Mail Security

    lockbin.com[1] has a reasonable method for restoring some security to the e-mail arena. The service is a little bit inconvenient so it does not qualify for daily use, but especially when you are dealing with someone who resists taking any precautions at all, this might be quite a good solution.

    To use lockbin you first deliver a shared password to the other person, preferably by some means other then the same e-mail address lockbin is going to use to announce the arrival of a message. Then on lockbin's SSL-encrypted (https) website compose and send your message.

    The recipient receives an e-mail which says, in part:

    "Hopefully, your friend has already given you a special 'Secret Word', which will un-encrypt the message so you can read it."
    containing a link back to his waiting message on the lockbin website. The recipient must then enter the 'Secret Word' to see the message. If he wishes, the recipient can then reply to you using lockbin again, in the same window.

    Needless to say there are some security holes in this arrangement, like the need to trust the system administrators of lockbin, and the need to send the password by some preferably secure channel.

    [1] https://lockbin.com/

    posted at: 05:02 | path: /Security/e-mail | permanent link to this entry

    Thu, 12 Nov 2009


    /Security/e-mail: Big Brother Taking Over Europe

    This article[1] talks about the increasingly tight noose around the throats of users of electronic communications in Europe:

    Now, the Interception Modernisation Programme plans to force all electronic communication providers (wireless companies, cable companies, internet service providers, etc.) to keep a record of every communication by every customer for a period of 1-year, and make the data available to 653 public agencies.

    You must consider all unencrypted e-mail communications to be *public* communications being read by any number of hackers and bureaucrats, and susceptible to being posted on a public website at any time.

    I really do not understand people who do take measures to protect their privacy, which seems to be the vast majority of people. But there are a lot of things I do not understand, I guess....

    [1] http://www.sovereignman.com/personal-privacy/spying-on-your-phone-and-email

    posted at: 00:58 | path: /Security/e-mail | permanent link to this entry