GitLab

When a calendar is added to Evolution using "New Calendar" -> "On The Web" and an HTTP URL is entered, the URL is accessed via HTTP (not HTTPS) for each refresh, even when the server redirects to HTTPS with 301 Moved Permanently and sends a Strict-Transport-Security header.

If the calendar requires HTTP basic authentication and the credentials are stored in the keyring, a MITM attacker can perform a SSL stripping attack to obtain them because if an attacker prevents the redirect to HTTPS, Evolution sends the credentials over HTTP without asking the user.

This behavior happens in the newest stable release of Evolution (3.34.1) and also an older release used by Ubuntu (3.28.5). However, the newest release even sends the credentials unasked via HTTP (before the redirect to HTTPS happens), which means that even a passive eavesdropper could obtain the password. This is not possible for the older version (3.28.5) I tested.

Steps to reproduce:

1. Set up a server which

• provides an iCal file via HTTP and HTTPS
• requires HTTP basic authentication
• redirects all HTTP requests to HTTPS
• sends the Strict-Transport-Security header
• logs the used protocol (HTTP or HTTPS) and Authorization header for each incoming request

2. In Evolution, add the HTTP URL to the iCal file via "New Calendar" -> "On The Web" and enter the credentials
3. Refresh the calendar

For each refresh with version 3.34.1 of Evolution, you will see two requests (the first one via HTTP, the second one via HTTPS), both with the provided credentials. For each refresh with version 3.28.5 of Evolution, you will again see two requests (the first one via HTTP, the second one via HTTPS), but only the second one with the provided credentials.

This issue could be solved by implementing HTTP Strict Transport Security (HSTS) in Evolution.