-2

I'm trying to understand how the command STARTTLS in IMAP works exactly and what becomes different when it's sent. After I've sent the command "STARTTLS" before login process and received the response "OK Begin TLS negotiation now" as a client, does anything change for me as a client in the futher communication, that is, the format of the requests and responses, some additional information, etc? I mean the API level, not the lower levels.

closed as off-topic by Stephen Harris, ilkkachu, Michael Homer, Julie Pelletier, Scott Aug 14 '16 at 6:47

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I'm voting to close this question as off-topic because it's an IMAP protocol question not related to Unix & Linux as defined in the help center. – Michael Homer Aug 14 '16 at 0:41
  • 1
    What changes is that the communications are therefore encrypted. Don't expect to manually handle an encrypted connection. – Julie Pelletier Aug 14 '16 at 6:21
  • 1
    @MichaelHomer I disagree. Understanding protocols commonly used by Unix systems is on-topic here. – Gilles Aug 14 '16 at 9:30
  • 2
    @Gilles: It doesn't seem to fit under any of the help center categories. I don't see how that's really anything but boat Unix, in any case. – Michael Homer Aug 14 '16 at 10:04
  • 1
    If the question were about, e.g., 9P, then sure, but IMAP has no particular Unix connection. I don't think questions about HTTP headers are on topic either. I could be wrong on both counts, of course, but it'll be strange to be the less expansionist one for once. – Michael Homer Aug 14 '16 at 10:14
3

The STARTLS process tells the client and server to start negotiating an encrypted connection, so all further data will be TLS (SSL, close enough) encrypted. This will prevent people from sniffing your traffic (eg usernames, passwords).

Now some servers can be configured to provide different services; for example an IMAP server may refuse to allow the LOGIN command over a plain connection but will allow it over a TLS encrypted connection.

We can see the difference. In this example, for a normal IMAP connect we are shown:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.

Note the "LOGINDISABLED" part.

If we connect to the same server via TLS

* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN

Now we can see "AUTH" is available, so I can attempt a login.

IMAP isn't the only service that may work this way; eg SMTP with plain connections:

250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

And with TLS

250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Again there's a new AUTH command available.

  • I already know that. – Johshi Aug 13 '16 at 15:19
  • Then what is your question? These commands are the API layer. – Stephen Harris Aug 13 '16 at 15:27
  • What becomes different after – Johshi Aug 13 '16 at 15:35
  • 1
    @Johshi I'm with Stephen: this answer describes what STARTTLS changes, this is exactly what you asked. If this is not what you meant to ask, you need to ask a new question that clearly explains what you mean to ask. – Gilles Aug 13 '16 at 21:36
  • 2
    @Johshi I think the answer to your update is “nothing else changes”. The protocol over the TLS layer is exactly the IMAP protocol, but over TLS (which itself is over TCP) instead of over TCP. That is, Stephen's answer is complete. He doesn't describe other changes because there are no other changes. – Gilles Aug 14 '16 at 9:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.