Index of /stubmail/docs

Icon  Name                    Last modified      Size  Description
[DIR] Parent Directory                             -   
[TXT] README.html             01-Aug-2006 10:51  7.9K  
[   ] REQUIRED_MODULES        01-Aug-2006 10:51   39   
[   ] block_diagram.odg       01-Aug-2006 10:51   12K  
[   ] block_diagram.pdf       01-Aug-2006 10:51   71K  
[TXT] index-mengwong.html     01-Aug-2006 10:51   19K  
[   ] jah_presentation.odp    01-Aug-2006 10:51   19K  
[   ] poll_diag.odg           01-Aug-2006 10:51   11K  
[   ] poll_diag.pdf           01-Aug-2006 10:51   14K
Stubmail README

Stubmail Readme

Stubmail Overview

Stubmail consists of three main parts. The client-side utilities are http2mbox2 and smtp2stub. The server is post_manager.

http2mbox2 fetches mail from senders, decryptes it and appends it to the local mailq (default unix location: /var/spool/mail/$LOGNAME.

smtp2stub accepts mail from an smtp client, checks for stubmail support at the recipient end and either stores the mail (on the sender's server - the sender must have stubmail support) or passes the mail on to the legacy smtp server. smtp2stub buffers mail in memory, so it is possible that mail will be lost if smtp2stub encounters problems saving the mail in one of these two ways. smtp2stub is configured via the ~/.stub/stub.conf file. If the file is missing, it will err and display a sample configuration file.

post_manager acts as a CGI on the sender's server. It will spawn a deamon the first time it is called as a CGI. It listens on UDP port 2225 (a high port, since it is expected to run as a non-root user). It stores mail in /var/spool/stubmail. This directory must be owned by the same user as the one running the CGI.

All requests to post_manager by the sender or the recipient use an efficient protocol to transmit data. Data is sent using a normal HTTP POST method, but multipart/form-data encapsulation is used to avoid the inefficiency of url-encoding the data. Furthermore, 8bit encoding is used to avoid the inefficiency of base64 or other alternatives.

Network Model

Mail is stored on the sender's server. Domain owners decide based on their own out-of-band security policy which users may store mail on their servers, how much mail they may store, etc. Since spam is effectivly prevented, many common mailserver security concerns are eliminated. There is no incentive for abuse of mailservers, except denial of service.

Order of operations:

  1. Sender sends rfc822 message via SMTP to Stubmail
    1. Stubmail generates GPG key-pair for sender, if necessary.
    2. Stubmail stores public key on sender's key-server.
    3. Stubmail retrieves recipient key from recipient's key-server, if necessary.
    4. Stubmail encrypts message with recipient's key and signs message with sender's key.
    5. Stubmail saves message to sender's message store.
  2. Recipient checks for mail from Sender via http2mbox2
    1. Stubmail compiles sender list from GPG keyring.
    2. Stubmail checks internal DB for existing sender cookies. (optional)
    3. Stubmail sends small UDP mail status request to each sender's server where cookie exists.
    4. If cookie does not exist OR if response was not heard OR if response indicates mail waiting:
      1. Stubmail generates a signed message requesting list of new mail from server, with (new) cookie.
      2. Stubmail sends signed request to server.
      3. Server returns message list and (optionally) saves cookie for future UDP requests.
    5. Stubmail requests each message from server.
    6. Stubmail checks signature of messages.
    7. Stubmail decryptes messages using recipient's private key.
    8. Stubmail appends decrypted plain-text to user's mailq.
    9. Stubmail deletes each message from server.

DNS

DNS is the root of authority and security on the internet. Stubmail adheares to this traditional convention. User's public keys are found on keyservers specified in their domain's DNS records. Mail servers are also found using the domain's DNS. Each domain must add three records to their zone:

_stub._udp.$DOMAIN SRV $PRI $SEQ $PORT $HOSTNAME

This "stub" record indicates what server recipient agents should ping using lightweight UDP. $PORT is typically 2225. If a different port is to be used, it must be configured in the source for Stubmail.pm ($SRV_PORT).

_pks._tcp.$DOMAIN SRV $PRI $SEQ $PORT $HOSTNAME

This record indicates where to find the key server for the domain. $PORT is typically 11371.

_post._tcp.$DOMAIN TXT $PRI $SEQ $PORT $HOSTNAME $PREFIX

This record indicates where to find the post_manager CGI. $PREFIX indicates the path to the CGI. For example: "cgi-bin/stubmail/post_manager". A TXT record is used for this record because SRV does not support the additional $PREFIX field.

Example zone file records: 

_stub._udp.stubmail.example.com.   SRV     10 5 2225 www.example.com.
_pks._tcp.stubmail.example.com.    SRV     10 5 11371 www.example.com.
_post._tcp.stubmail.example.com.   TXT     "10 5 80 www.example.com. cgi-bin/stubmail/post_manager"

Security Concerns

Stubmail does not encrypt data on the wire. Instead, the underlying messages being transported are encrypted at the sender and decrypted at the recipient.

In the default implementation, messages are removed from the sending server as soon as they are received.

Once a key is downloaded for a sender, the key is added to the user's local GPG keyring. Typically, keys are downloaded when mail is first sent to the person.

Mail is downloaded from all users in the keyring. Thus a typical key-exchange is accomplished when each user sends mail to the other. Note that if only one user sends mail, it will never be received. Each user must send a message or otherwise add their coorespondent to their GPG keyring.

The default configuration makes some security compromises to ease adoption - hiding the details of key-management from the user. Users who wish to manage their own keyrings (by exchanging keys in person, for example) are free to do so. Stubmail will preserve imported keys. No mail will be retrieved from messages signed with keys which differ from the keys in the local keyring. No such differing keys will be imported into the user's local keyring if a key already exists with the same address. Keys are only imported into the keyring when a user sends mail. Thus no imposter or foreign key can be foisted on a recipient.

Stubmail's design is resistant to denial of service attacks. Clients must provide a signed request in order to establish a session with the server. The server can perform various sanity checks prior to a full-blown signature verification to deflect bogus requests. The UDP server is non-forking and efficient. If UDP flooding is encountered, the UDP server can be disabled entirely and legitimate clients will fall back on the heavy-weight signed HTTP request method. On the other hand, if the HTTP server is under attack, it could be configured to ignore requests from clients who have not already attempted using the UDP method.

Possible attacks

Attackers snooping on data transfer can see encrypted message bodies and can identify who is sending mail to who, and how much mail is being sent.

Man-in-the-middle attacks can poison the initial key-exchange between sender and recipient. Once the key-exchange has been poisoned, subsequent messages can be forged.

If the MITM misses the initial key exchange, they cannot read or alter the messages, except by preventing them from being exchanged at all (denial of service).

Hijacking the UDP check-for-messages protocol: Because stubmail uses a lightweight cookie-based protocol when checking for new messages, there are some possibilities for tampering with this conversation. If an attacker can snoop on the UDP request for messages, a false response can be forged to indicate there are or are not new messages waiting. For this reason, it may be desirable to use the heavy protocol periodically, even when UDP reports no messages waiting. If this is desired, simply "rm /tmp/stubmail_cookies.*" at the client or server.

Encryption keys and messages are not secure on-disk. The user's system is assumed to be secure. Users should implement additional layers of security, such as full-disk encryption. Future native (non smtp-legacy) implementations of stubmail may overcome this by incorporating more local encryption.