Hi,
just ran into the same /unfortunately auto-closed after 7 days) issue with sending emails over SSL mentioned here after the upgrade to 4.6 but using Netcup instead of Google. So it seems to be a KNIME, JAVA, … issue and not related to the Google side. Are there any updates on this?
While the workaround with STARTTLS on another port works it is just that, a workaround. Sending emails via SSL is to be preferred from a privacy and security perspective…
Regards,
Lars
Using STARTTLS is as secure as SSL. In fact STARTTLS is the preferred way.
I definitively don’t claim to be an expert on that field, but my little research on that topic said otherwise:
A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client’s request to start TLS and the server’s response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.
If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, […]
Bewusst oder unbewusst könnten Provider als man-in-the-middle die verschlüsselte Übertragung deaktivieren. Es wird einfach die Meldung 250-STARTTLS gefiltert und überschrieben. Scheinbar verfügen alle DSL-Provider über die Möglichkeit, dieses Feature bei Bedarf für einzelne Nutzer zu aktivieren. Einige E-Mail Clients verwenden standardmäßig die Option “STARTTLS wenn möglich”. Diese Einstellung ist genau in dem Moment wirkungslos, wenn man es braucht, weil der Traffic beschnüffelt wird. […] Auch die IETF empfiehlt in RFC 8314 “SSL/TLS” gegenüber “STARTTLS” zu bevorzugen.
Der Hauptnachteil von STARTTLS ist, dass dieser Upgrade-Mechanismus gegen Man-in-the-Middle-Angriffe anfällig ist. Durch Manipulation der Klartextbefehle kann der Angreifer die TLS-Verschlüsselung verhindern. Zum Schutz vor einem solchen Downgrade-Angriff sind zusätzliche Maßnahmen erforderlich, beispielsweise DANE oder MTA-STS. Ein Nachteil in Verbindung mit einer Firewall kann sein, dass Deep Packet Inspection auf Anwendungsschicht benötigt wird, um verschlüsselte und unverschlüsselte Verbindungen zu unterscheiden.
In den folgenden Jahren nahm die Verbreitung von TLS weiter zu. Bei einer Neubewertung im Jahr 2018 bevorzugen die STARTTLS-Entwickler nunmehr implizites TLS. Von einer Klartextübertragung wird gänzlich abgeraten.[1]
In principle this is correct but I was assuming that a TLS connection was enforced when selecting STARTTLS. The connection would not get established if any of the situations you mentioned happened. However, I just check the source code and apparently the node does not enforce a TLS connection if STARTTLS is selected. And this is indeed a problem. I have opened a bug ticket for this problem (AP-19571 for future reference).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.