Closed Bug 1726322 Opened 4 years ago Closed 3 years ago

2 suspicious connections by Thunderbird

Categories

(Thunderbird :: Untriaged, defect)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: D-33c6yu, Unassigned, NeedInfo)

Details

(Whiteboard: [support])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

In the early morning, I checked my network connections and I noticed two unexpected connections by Thunderbird:

  1. An IMAP connection to a server with hostname beginning with "racondbtest-ho-b0", which is not the usual server for my email services.
  2. A connection to a Cloudflare server 172.67.74.82

Actual results:

Two suspicious connections:

  1. An IMAP connection to a server with hostname beginning with "racondbtest-ho-b0", which is not the usual server for my email services.
  2. A connection to a Cloudflare server 172.67.74.82
    Can you explain either of these?
    I'm using only Comcast and Gandi email accounts, both are IMAP.

Expected results:

No suspicious connections.

The next day I found that Thunderbird was accessing Cloudflare via HTTPS again at 104.26.2.27, and Fastly via HTTPS at 151.101.189.137.
Why is it making non-mail-server accesses?

There's nothing in Thunderbird that would make IMAP connections you don't have accounts for. Not sure what kind of logging you have, but in the likely case it's external to Thunderbird is it likely the hostname is guessed by reverse look-up? If so it will not reflect what Thunderbird actually asked for whenever the "nice" names are pointing at a big cloud back-end which is pretty common these days. A hostname "beginning with" isn't enough for us to do any further lookups, but you could do a DNS lookup on the server name stored in your Thunderbird account information and compare that with the IP address in the log or a DNS lookup on that name you saw and see if they match.

Same deal with the Cloudflare HTTPS connection. You can't tell from the IP address what hostname was actually requested. If your logging showed the SNI or Host: header then you could tell. https://www.thunderbird.net/ is hosted on Cloudflare, and that's the source of the welcome banner when you first open the client so that doesn't disturb me at all. Looks like the Privacy Policy is out of date since it says Thunderbird assets are hosted on Amazon's cloud. Some are still on AWS/cloudfront, but not all.

The privacy policy lists a lot of different types of requests Thunderbird makes: https://www.mozilla.org/en-US/privacy/thunderbird/

I didn't see any hosted on Fastly, but I didn't do a deep dive. Since that Welcome panel is remote it might itself load assets from a different CDN, just like any web page. In any case I don't see a security threat here that needs to be hidden. More people will be able to help if they can see the bug.

Group: mail-core-security
Whiteboard: [support]
Flags: needinfo?(D-33c6yu)

The Cloudflare connection may be DNS over HTTPS.

(In reply to D-33c6yu from comment #1)

The next day I found that Thunderbird was accessing Cloudflare via HTTPS again at 104.26.2.27, and Fastly via HTTPS at 151.101.189.137.
Why is it making non-mail-server accesses?

Suggest you check Edit > Preferences > General.
Scroll down to the Network & Disk Space section.
Click the Settings button for configuring how Thunderbird connects to the Internet.
Check the settings and confirm you haven't enabled "DNS over HTTP" using Cloudflare and Fastly.

Check the settings and confirm you haven't enabled "DNS over HTTP" using Cloudflare and Fastly.

I confirm that it isn't checked.

Also here are today's unexpected connections, reported by netstat:
ec2-54-88-151-21.compute-1.amazonaws.com
server-52-84-169-102.sea19.r.cloudfront.net
151.139.128.14 (stackpath)

Flags: needinfo?(D-33c6yu)

This is bug is going nowhere. The first two sites are places I would expect Thunderbird to connect to in a normal day. While I have no idea what stackpath is I don't have access to the mail, calendars, chat services, newsgroups and the body of your email that you have read or the remote images in your email to know what is suspicious and what is not. Accessing via HTTP is also normal.

So what is suspicious about these connections, other than you don't know about them?

I have no idea how you checked the setting in Thunderbird as suggested for DNS over HTTP. I am using V91 and there is no setting in preferences for HTTP over DNS as yet. So there was none in V78 either. There is a setting in Firefox, but that is irrelevant to Thunderbird. So what did your check?

You missed the setting. On 91 (and earlier AFAIK). preferences->connection settings. Scroll to the bottom of the proxy settings page.

Attached image Firefox options. 93.0a1

Comment on attachment 9238268 [details]
Firefox options. 93.0a1

Funny how Firefox can create a view of the connection preferences that is clear and unequivocal, but I have to figure out it is hidden behind a scroll bar in Thunderbird. One that has been deemphasised for clarity. (A pale grey, looks like it is disabled.)
Of course, I missed it, or I would not have said what I did. I only stumbled upon it just now when I went to look for the third time since you suggested I missed it. Nothing like an intuitive user interface that presents information in an east to view manner.

All this searching and scrolling to "simplify" what previously had a location where it could be found. I dumped Microsoft Office when they got a ribbon that hid everything from me, for my convenience. This is just the same. Now we have to scroll in a dialog because good design is not needed if you just make endless options pages.

(In reply to Daniel Veditz [:dveditz] from comment #2)

There's nothing in Thunderbird that would make IMAP connections you don't have accounts for. Not sure what kind of logging you have, but in the likely case it's external to Thunderbird is it likely the hostname is guessed by reverse look-up? If so it will not reflect what Thunderbird actually asked for whenever the "nice" names are pointing at a big cloud back-end which is pretty common these days. A hostname "beginning with" isn't enough for us to do any further lookups, but you could do a DNS lookup on the server name stored in your Thunderbird account information and compare that with the IP address in the log or a DNS lookup on that name you saw and see if they match.

Same deal with the Cloudflare HTTPS connection. You can't tell from the IP address what hostname was actually requested. If your logging showed the SNI or Host: header then you could tell. https://www.thunderbird.net/ is hosted on Cloudflare, and that's the source of the welcome banner when you first open the client so that doesn't disturb me at all. Looks like the Privacy Policy is out of date since it says Thunderbird assets are hosted on Amazon's cloud. Some are still on AWS/cloudfront, but not all.

The privacy policy lists a lot of different types of requests Thunderbird makes: https://www.mozilla.org/en-US/privacy/thunderbird/

I didn't see any hosted on Fastly, but I didn't do a deep dive. Since that Welcome panel is remote it might itself load assets from a different CDN, just like any web page. In any case I don't see a security threat here that needs to be hidden. More people will be able to help if they can see the bug.

I don't think we host anything elsewhere.

Flags: needinfo?(sancus)

Thunderbird primarily uses AWS for hosting and both Cloudflare and Cloudfront as reverse proxy CDNs depending on the particular site. The privacy policy isn't meant to be an exhaustive list of services we use or anything like that.

Random IPs and such are useless though, as all CDNs assign edge level connections at the DNS level. But we certainly don't use Fastly, I can say that much. If Thunderbird is actually making these connections somehow, output from the error console would be more instructive.

Flags: needinfo?(sancus)

Are you still seeing this issue with version 91?

Flags: needinfo?(D-33c6yu)
Whiteboard: [support] → [closeme 2022-01-05][support]

Resolved per whiteboard

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2022-01-05][support] → [support]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: