Bug #9382

Adjust manual Thunderbird EHLO test for StartTLS

Added by alant 2015-05-12 11:08:26 . Updated 2018-08-18 12:06:27 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Start date:
2015-05-12
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

Currently, test instructions reads:


* Also check that the EHLO/HELO SMTP message is not leaking anything
  at the application level:
  1. Start Claws using the panel icon.
  2. Disable SSL/TLS for SMTP in Claws (so take precautions for not
     leaking your password in plaintext by either changing it
     temporarily or using a disposable account). I don't find a provider that allows that...
  3. Run `sudo tcpdump -n -i lo -w dump` to capture the packets before
     Tor encrypts it, then close tcpdump
  4. Check the dump for the HELO/EHLO message and
     verify that it only contains `localhost`: `tcpdump -A -r dump`

But we have no test infrastructure to acces an SMTP server which allows unencrypted login. It seems last testers thus looked at the 1st EHLO, before the STARTTLS command.

However, the RFC reads (https://www.ietf.org/rfc/rfc2487.txt):


5.2 Result of the STARTTLS Command

   Upon completion of the TLS handshake, the SMTP protocol is reset to
   the initial state (the state in SMTP after a server issues a 220
   service ready greeting). The server MUST discard any knowledge
   obtained from the client, such as the argument to the EHLO command,
   which was not obtained from the TLS negotiation itself. The client
   MUST discard any knowledge obtained from the server, such as the list
   of SMTP service extensions, which was not obtained from the TLS
   negotiation itself. The client SHOULD send an EHLO command as the
   first command after a successful TLS negotiation.

We are thus not checking the right EHLO.

Subtasks

History

#1 Updated by BitingBird 2015-05-12 17:57:01

  • Affected tool set to Email Client

#2 Updated by intrigeri 2015-05-25 09:42:32

  • Subject changed from We should test the 2nd EHLO command when checking for claws leaks to Adjust manual Claws Mail EHLO test for StartTLS
  • Category set to Test suite
  • Status changed from New to Confirmed
  • Type of work changed from Test to Contributors documentation

Let’s consider the current phrasing (cleartext SMTP auth.) as a workaround, and adapt this manual test to focus on StartTLS, which is more common these days. One way to do it is to look at Claws Mail network trace dialog. Of course it’s not blackbox testing, but it would be better than not checking at all. Another way out would be to check in Claws Mail’s source code if there are any chances that a different EHLO is sent after StartTLS than before.

#3 Updated by Anonymous 2016-01-03 19:22:56

  • Assignee set to kytv
  • Deliverable for set to 268

Check if this needs to be done for Icedove, instead of Claws

#4 Updated by Anonymous 2016-01-03 19:25:34

  • Subject changed from Adjust manual Claws Mail EHLO test for StartTLS to Adjust manual Icedove EHLO test for StartTLS

#5 Updated by Anonymous 2016-01-03 19:27:10

  • Assignee deleted (kytv)
  • Target version set to Tails_2.0

#6 Updated by Anonymous 2016-01-27 12:01:22

  • blocks Feature #10737: Update our design documentation to the return of Icedove added

#7 Updated by Anonymous 2016-01-27 17:50:00

  • Status changed from Confirmed to In Progress

I’ve tried this for Icedove/Torbirdy.

The EHLO command appears as EHLO[127.0.0.1] just after connecting to the SMTP server when using STARTTLS and also when using no encryption. That’s indeed the first EHLO.

#8 Updated by Anonymous 2016-01-27 18:05:25

  • Assignee set to anonym
  • Feature Branch set to 451f:tails/feature/9493+Icedove_manual_tests

I have adjusted the documentation to match this with Icedove. However I would need more technical insight on the raised issue (RFC second EHLO command when using STARTTLS). For me, the second command is encrypted, so, why should I be able to see this?

#9 Updated by Anonymous 2016-01-27 18:07:49

oops, i tentatively assigned this to anonym, because i thought that he might have an idea.

#10 Updated by Anonymous 2016-01-27 18:22:31

  • Status changed from In Progress to Resolved

Anonym says:

presumably they (the tow EHLOs) are the same though
we already make the assumption that the EHLO:s we see when testing with plaintext (and the first one for StartTLS) are the same as when SSL/TLS is enabled

I’ve checked the Icedove code too: in mailnews/compose/src/nsSmtpProtocol.cpp we have:


 348       // is a FQDN known for this system?
 349       char hostName[256];
 350       PR_GetSystemInfo(PR_SI_HOSTNAME_UNTRUNCATED, hostName, sizeof hostName);
 351       if ((hostName[0] != '\0') && (strchr(hostName, '.') != NULL))
 352       {
 353           nsDependentCString cleanedHostName(hostName);
 354           // avoid problems with hostnames containing newlines/whitespace
 355           cleanedHostName.StripWhitespace();
 356           aResult += cleanedHostName;
 357       }
 358       else
 359       {
 360           nsCOMPtr<nsINetAddr> iaddr; // IP address for this connection
 361           // our transport is always a nsISocketTransport
 362           nsCOMPtr<nsISocketTransport> socketTransport = do_QueryInterface(m_transport);
 363           // should return the interface ip of the SMTP connection
 364           // minimum case - see bug 68877 and RFC 2821, chapter 4.1.1.1
 365           rv = socketTransport->GetScriptableSelfAddr(getter_AddRefs(iaddr));

I suppose that Torbirdy sets the IP address to 127.0.0.1.

And there do not seem to be different EHLOs in the code.

I believe thus that this ticket can be closed.

#11 Updated by intrigeri 2016-01-29 15:23:45

  • Status changed from Resolved to Confirmed

It looks like there’s been a few misunderstandings.

The whole point of this ticket is to have a test (manual or automated) to ensure that the property we are interested in (nothing but “localhost” or “127.0.0.1” leaked via EHLO) is always verified.

AFAICT, a one time check was done, that relied on code review; this is great! But the way it’s done, it’s not something that we can do every time we do a Tails release, so the quality assurance / regression testing part of this ticket is left unadressed. So I don’t think that this ticket can be considered as resolved as-is, and I’m reopening it.

However, as I see it, the only part of the ticket that was a blocker for SponsorS_M4 was the one-time check that was done by u, so that on Feature #10737 we can report about it. Which implies that we’re good on this side, and there’s no emergency to work on the remaining bits of this ticket, and nobody formally has to put it on their plate due to existing commitments.

#12 Updated by intrigeri 2016-01-29 15:26:15

  • Assignee deleted (anonym)
  • Target version deleted (Tails_2.0)
  • Feature Branch deleted (451f:tails/feature/9493+Icedove_manual_tests)
  • Deliverable for deleted (268)

#13 Updated by anonym 2016-03-08 19:06:16

  • blocked by deleted (Feature #10737: Update our design documentation to the return of Icedove)

#14 Updated by anonym 2016-03-08 19:06:19

I’m removing the blocker in Feature #10737 because its branch was merged and the ticket closed. If there is something in the docs that needs to be adapted, let’s open a new ticket.

#15 Updated by Anonymous 2018-08-18 12:06:27

  • Subject changed from Adjust manual Icedove EHLO test for StartTLS to Adjust manual Thunderbird EHLO test for StartTLS