From a094f94f7c2a1156c5ffc9cbf37cd482d5f8468f Mon Sep 17 00:00:00 2001 From: Eduardo Chappa Date: Sun, 30 Jun 2019 20:21:45 -0600 Subject: * Update to some documentation on security using SSL, TLS and STARTTLS. --- pith/pine.hlp | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 99 insertions(+), 3 deletions(-) (limited to 'pith') diff --git a/pith/pine.hlp b/pith/pine.hlp index 9a3752bb..9457f6fa 100644 --- a/pith/pine.hlp +++ b/pith/pine.hlp @@ -140,7 +140,7 @@ with help text for the config screen and the composer that didn't have any reasonable place to be called from. Dummy change to get revision in pine.hlp ============= h_revision ================= -Alpine Commit 352 2019-06-22 10:13:44 +Alpine Commit 353 2019-06-30 20:21:37 ============= h_news ================= @@ -1690,6 +1690,13 @@ a folder-collection, or a news or SMTP server). This will disable certificate validation. On the other hand, if you are attacked, you will get no warning if you do this. +

When you get a error indicating a self-signed certficate from the +remote server, you can download and install the certificate for that +server. Avoid using the /NoValidate-Cert modifier. Alpine cannot help you +with this process because certificates are part of the system and are not +under the control of the user. Find directions on how to download and +install certificates for your system using your favorite search engine. +

<End of Cert Validation Failures help> @@ -20867,7 +20874,8 @@ If that fails then a non-encrypted connection will be attempted instead. This is a unary parameter indicating communication with the server must take place over a TLS connection. If the attempt to use TLS fails then this parameter will cause the connection to fail instead of falling -back to an unsecure connection. +back to an unsecure connection. Learn more +about security considerations when you use this option.

/tls
@@ -20988,7 +20996,8 @@ It indicates that the connection should be made to the Submit server (RFC 3676) (port 587) instead of the SMTP port (25). At the time this help was written the submit option was equivalent to -specifying port 587. +specifying port 587. Learn more +about security considerations when you use this option.

/submit
@@ -21089,6 +21098,93 @@ specification by concatenating the parameters. For example:
foo.example.com:port/user=katie/novalidate-cert/debug

+

+<End of help on this topic> + + +======= h_security_considerations ======= + + +SSL, TLS, STARTTLS and More Security Considerations + + +

SSL, TLS, STARTTLS and More Security Considerations

+ +The purpose of this text is to educate users on how to best choose +the type of security connection to a remote server using the SSL and TLS +encryption protocols. + +

+In the past, and when Alpine originally started to support encrypted connections +to remote servers, the /ssl modifier was needed, and it meant any of the SSLv2 +or SSLv3 protocols. Those encryption protocols are considered not fully secure +anymore, and in fact, you might not be able to use them anymore. + +

Today the /ssl modifier means to use the most secure encryption +protocol between your version of Alpine and what the server supports. This +might mean more modern protocols, such as TLS 1.0, TLS 1.1, etc. As of +this writing, Alpine supports connection using TLS 1.3. These protocols +are considered more secure today and they should be preferred over the old +SSL protocols. + +

A source of confusion for Alpine users might be the meaning of the +modifier /tls with respect to the names of the encryption protocols, such +as TLS 1.2. The meaning of /tls is to start an encrypted connection to a +server after an insecure connection has been established, and we will +discuss this later in this help text. + +

The best way to start an encrypted connection to a server is to use the +/ssl modifier. If your provider allows encrypted connections on port 993 +for IMAP, or port 995 for POP3, or in port 465 for SMTP, just define your +server by adding the /ssl modifier and do not add the port to the server. +Alpine knows that the secure connection will be done in the correct port, +and will use the most secure encryption available between Alpine and the +server. You only need to use the port number when it is different from the +default port numbers for this type of connections, and those were given +above. + +

Most email service providers identify secure connections by saying +"SSL or TLS". In this case, use the /ssl modifier, and only use +the port number in case it is different to the ones above. + +

If your service provider says to use STARTTLS, then you need to use the +/tls modifier. If your service provider gives you the option to use SSL or +TLS and to use STARTTLS choose the secure port and choose the /ssl +modifier. This is because connections using the /tls modifier can be +attacked and your username and password can be stolen by a hacker. The next +paragraph describes in short how to do this. + +

When you use the /tls modifier, Alpine connects insecurely to the +remote server. Because the connection is insecure, it is possible that you +connect to a different server, which connects you to the real server. This +is called "man-in-the-middle" attack, and so your communication +will pass through the hackers computer before it reaches the real target. +An example of a possible man-in-the-middle is your internet service provider, +or your employer in some instances. +This means that the hacker can modify the replies from the correct server +and give you the illusion of security before you are actually connected to +the secure server. Therefore, you might disclose your username and +password to the hacker before you establish a secure connection to the correct +server. + +

Therefore, if possible avoid using STARTTLS (for IMAP and POP) or SUBMIT +for SMTP (in port 587), as these are subject to attack. If possible +ask your provider for secure connections for SSL or TLS in the secure ports +993 for IMAP, 995 for POP or 465 for SMTP. + +

In the current state, even as of TLS 1.3, these protocols are considered +secure but they do not protect your privacy. For example your internet +service provider might track to which servers you are connecting securely. +Encryption protocols are evolving to not only protect the security of your +data, but also your privacy. + +

Other type of errors can lead to insecure connections. An example is +when the name of the server as provided by the user does not match the +name of the name of the server in the certificate. +Read more about security errors +of this type and learn how to protect yourself against this type of +errors. +

<End of help on this topic> -- cgit v1.2.3-70-g09d2