Secure email

With the cryptographic signature, the sender of a mail provides information that enables recipients to verify his or her identity.

In mail programs, a cryptographically signed mail is clearly marked (usually by a letter symbol or a seal symbol). By clicking on the symbol, further information about the signature can be displayed. Examples:

With encryption, the sender of a mail ensures that it can only be read by the recipient. Both sender and recipient must have a user certificate.

Please note that you always need the private key to decrypt encrypted emails, files etc.. This also applies to emails, files etc. that were encrypted in the past using user certificates that have now expired. It is therefore advisable to keep expired user certificates (or private keys in general) if you still want to decrypt old e-mails, files etc. (with the expired user certificate/key).

In order to be able to cryptographically sign and/or encrypt mails, a user certificate is required. While a user certificate is required for encryption for sender and recipient, it is sufficient for the cryptographic signing of a mail if the sender has a user certificate.

You can apply for a user certificate here (incl. step-by-step instructions):

One must be aware that in principle all contents incl. sender and subject of an e-mail can be faked (with the exception of parts of the header information). In particular, the sender's address and the sender's display name can be faked. In combination with large data leaks from other phishing campaigns (such as Emotet), deceptively genuine phishing emails can be created with the leaked data, which are based on old mail histories, for example.

The only way to unambiguously verify a mail sender is to cryptographically sign mails so that the recipient can check this signature.

Do not hesitate to look up the phone number of a mail contact -outside the mail- and contact the alleged sender by phone for verification if signatures are not available.

Mail filtering for malware (including viruses) and spam is carried out centrally at Leibniz Universität Hannover by the computer centre.

Information on this, especially on the X-DFN spam levels, can be found here:

We generally recommend signing all mails cryptographically; the necessary certificate information for the exchange of encrypted mails is thereby distributed incidentally.

Sender, subject and content of a mail are freely selectable and cannot be used to verify the sender. Do not hesitate to look up the telephone number of a mail contact -outside the mail- and contact the supposed sender by telephone for verification if signatures are not available.

For the cryptographic signing of mails, a user certificate is required, which you can apply for here:

Mail programmes often display mails in HTML by default. This has the disadvantage that, for example, in the case of links, the link address can be disguised by a link text. In the case of a phishing mail, for example, a harmful link can be hidden.

We therefore recommend displaying incoming mails in text format only, in order to be able to recognise possible hidden contents / harmful links in phishing mails at a glance. This can either be set by default (recommended) or switched on for suspicious mails to be checked. Below are the configuration examples for the most common mail programs.

Microsoft has a support article on this.

Temporary: Display - e-mail - alternative for plain text

Permanent: The following command (+Mail restart) can be used to force the permanent display of plain text:

$ defaults write com.apple.mail PreferPlainText -bool TRUE

The setting can be reversed by executing the same command with FALSE instead of TRUE.

Establishing e-mail communication in HTML format involves some risks. For example, in the case of links, the link addresses can be disguised by a link text. In the case of a phishing email, for example, a harmful link may be hidden. In the case of established HTML mails, recipients may trust the content more and check links etc. less carefully, so that they are more susceptible to phishing mails that pretend to be established mails or copy them.

We therefore recommend that outgoing mails should only be written in text format and that HTML mails should not be established (if possible). If HTML mails must be sent, they should be cryptographically signed.

Below we show configuration examples for the most common mail programmes.

Apple has a support article on this. We recommend here to select the configuration so that all mails are written in text format.

Microsoft has a support article on this. We also recommend here to activate the changing of the format for all new messages.

Mail programs often abbreviate (known) e-mail addresses with a display name / alias. We recommend changing the settings so that the full e-mail address of the sender is always displayed in order to be able to detect phishing e-mails directly. (Often at least the display name is faked in phishing e-mails).

View tab - View settings - Columns. Then add the Recipient Name column there.

A lot of information is contained in the header information of mails. A detailed explanation of the individual components would go too far at this point. However, it is worthwhile to display the header information of mails in more detail than is usual by default in order to recognise phishing mails.

Apple has a support article on this.

Microsoft describes how to display Internet message headers in Outlook in a support article.

Opening & executing attachments is a major security problem. Malicious code is executed and spreads itself via file attachments. In many cases, by using cloud services or the LUIS download ticket service, it is not necessary to send files to each other. The automated opening & execution of attachments should be avoided at all costs. However, this is usually not active in mail programmes by default.

It should be avoided that external contents of an e-mail are downloaded from the internet as soon as the message is opened. Some mail programmes prevent this by default, others do not. Therefore, the correct setting should be checked.

Apple has a support article on this (uncheck the "Load removed content in messages" option there).

Support article from Microsoft.

Support article from Mozilla

When sending e-mails to many recipients via a distribution list, it may be useful to prevent the individual recipient from receiving the entire list of e-mail addresses.

For this purpose, after the e-mail has been composed as usual, the "To" field is not filled with the distribution list, but e.g. the recipient's own address. The "BCC" field is used as the actual address field. BCC stands for "Blind Carbon Copy" and has the advantage that for the individual recipient all others on the list remain covered and invisible.

The situation is different in small closed circles such as project groups. Here, the addresses should still be entered in the "TO:/AN:" or "CC:" field, especially if each recipient is to know which persons have received the mail.

In order to send signed mails to the subscribed persons via a mailing list (listserv) some points have to be considered:

When receiving non-cryptographically signed mails, you should exercise increased caution and strengthen your "security awareness". Be aware that almost all information in such mails can be faked. We advise:

• Implement / take into account the previously mentioned recommendations for the secure handling of e-mails in order to recognise phishing e-mails.
• Do not click on any links in e-mails (especially if the e-mail is displayed as HTML, as the "real" link may not be immediately visible then)
• In case of doubt, contact the sender by phone or in person (especially if there are requests for actions via e-mail, e.g. payments or requests to send access data).

You will need a user certificate, which you can then import into your mail programme.

No.

The text signature refers to a section of text (often at the end) of an e-mail. It is usually used to automatically insert information about the sender (name, address, telephone number, etc.) into newly created e-mails. It is not suitable for verifying a sender, as it can be chosen arbitrarily.

The cryptographic signature, on the other hand, is created by an asymmetric cryptosystem and enables recipients to verify the sender.

This can be realized with the help of PGP. You can find more information about this in our instructions.

Most spam phishing emails can be deleted and ignored. However, if you are unsure or have interacted with the sender, please contact security@luis.uni-hannover.de if in doubt.

Please send us the suspicious mails as an original attachment. Simply forwarding them is not sufficient in this case, as the relevant header information will be lost.

Yes.

Please send e-mails that have not been recognised by the anti-spam system but which you consider to be spam (as an original in the attachment) to:

spam@luis.uni-hannover.de

Sometimes it is necessary to send suspicious mails to the security team (e.g. if you have received suspicious mails and want more information). This must always be done as an original in the attachment, otherwise (e.g. when forwarding normally) the header information of the mail will be lost. The following shows how to do this.

Open the e-mail, then in the menu bar via "E-mail" - "Forward as attachment" (or via "Right click" on the mail you want to forward, then "Forward as attachment").

Unfortunately, Outlook discards important information, the X-DFN headers, when forwarding. However, these are needed by the mail team. Therefore, please forward spam mails with the respective webmail offer.

"Right click" on the mail --> "Forward as: Attachment".

An alternative way is by drag-and-drop:

If a mailbox is blocked, you will usually receive a message from LUIS or your responsible system administrator with further instructions.

After the mailbox has been unblocked, further steps must be taken to reactivate it. These are described here.

In order to send signed mails to the subscribed persons via a mailing list (listserv) some points have to be considered:

For further questions regarding email security, please contact security@luis.uni-hannover.de.