50

The problem you describe is not the use of STARTTLS by itself but the optional use of STARTTLS. Mail systems can be setup so that TLS is required in which case the mail will not be delivered if STARTTLS will fail or if the peer does not offer support for STARTTLS in EHLO. Required STARTTLS is is as safe as required TLS from start. The reason STARTTLS is not ...


26

I think you're overestimating the risk of enabling STARTTLS. Sure, there have been some incidents with OpenSSL recently, but does it mean we should all stop using HTTPS? In your situation, here is the trade-off: Using STARTTLS may open up security holes on your machines Not using STARTTLS will allow anyone snooping (on the network, on underwater cables...) ...


17

SSL-Session: Protocol : SSLv3 Cipher : AES256-SHA Obviously your server still has SSLv3 enabled. If you successfully disabled SSLv3 openssl s_client -ssl3 -connect ... should get something like this: ...SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40 ...SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: ... ...


13

Downgrade attacks are active attacks. Active attacks are much easier to detect, and are typically more difficult to perform, than their passive counterparts. Opportunistic encryption, such as optional STARTTLS in SMTP, mainly protects against passive surveillance where traffic is undetectably either analyzed while in transit, or stored for later analysis. ...


10

just for completeness: testssl.sh is a nice, console-based tool to check ssl-setups of any ssl/ts - enabled servers, in oposite to ssllabs


7

Two ways that I know of: If you have Webinspect, they have a check specifically for this. The simple way is to uncheck all protocols in IE with the exception of SSLv3 and see if you connect to the website.


6

STARTTLS can help you to provide reliable encryption between two companies, but it will not do it in the default setup: STARTTLS depends on the availability and the success of the STARTTLS command at the server MTA. Because the SMTP connection first starts without encryption an active man in the middle could simply modify the connection so that it looks ...


5

Though OpenSSL has some quality issues, it would be quite optimistic to believe that the rest of the software that you expose to the Internet fares better. OpenSSL is one of the most attacked pieces of software because it is a high-value target: The same library is used in many servers of many types (HTTPS, SMTP, IMAP,...) so any vulnerability has a wide ...


5

Firstly, you're confusing SSL/TLS and its implementations. Your server might use OpenSSL, but that doesn't mean the clients that connect to it will. Potential vulnerabilities depend very much on the context. If you're worried about OpenSSL-specific zero-day vulnerabilities, you might be able to find a mail server that uses another stack. In addition, ...


5

I’m wondering if this is always the case (e.g., because it is required by some sort of standard). Not really. The most recent RFC for SMTP RFC 5321 describes the format of the received header but this includes no such information, probably also because STARTTLS for SMTP is an extra standard. This standard is described in RFC 3207 and provides no information ...


4

SMTP with STARTTLS works by first creating a plain connection to the server and then upgrading it to TLS if the server supports it. The server shows support for STARTTLS within the response to the EHLO command. A man in the middle could simply modify the response from the server and remove the information that it supports STARTTLS. In this case the client ...


4

Small tangent - SMTP isn't secure, you're only talking about the MTA. TLS certificate validation modes (subject validation) is only a small subset, and doesn't matter if other concerns are addressed. For example, if you use SMIME or PGP, TLS might not matter. It depends on what your threats are. You say that TLS is preferred, and unencrypted if necessary. ...


4

In order: Is the use of opportunistic TLS just for backwards compatibility (with a known/used port)? Yes. When you have an existing service it is helpful to allow it to use TLS if the other end knows how, without requiring it to use TLS, to ensure you continue to be able to communicate with endpoints that do not know how. Is an ...


3

There are two sides of sending email encrypted via TLS: Between the sender and the email provider Between the email provider of the sender and the receiver's email provider (spam filters typically sit here) The security of the first connection has no impact on the spam rating on the receiver's side. However, the spam filter on the receiver side might ...


2

The nmap script 'ssl-enum-ciphers' is how I manage finding out what versions and ciphers are supported. Command is "nmap -p 443 --script ssl-enum-ciphers " The output can also be put into a grepable format. http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html


2

tl;dr: Because neither implicit nor explicit TLS is technically that bad; Because changing ways the Internet works takes time. This is essentially not one, but two different questions, and I'll address them separately. 1. Why are common services using implicit SSL not considered obsolete? As you may have already noticed, in recent years, large ...


2

Mail delivery is done hop by hop and not end to end. This means a typical sender in a company delivers its mail via SMTP (or some proprietary protocol) to the mail server which then delivers it via SMTP to the next mail server etc until the final mail server gets the mail and stores it. In some cases this can involves many hops which not only include simple ...


2

The man-in-the-middle sits between you and the SMTP server and hides the server capability broadcast of 250-STARTTLS (that's what deleting the "250 STARTTLS" response from the server means). Therefore, the client will not know that TLS is possible; it will not attempt TLS; and if the client has not been instructed to require it, the conversation will follow ...


2

I run a simple web service, and I need to securely send emails to users via PHP. Your exact requirements of "securely send emails" are unknown. But none of your proposals offers end to end security, i.e. depending on the path one or many parties can intercept and even modify the mail. In detail: SMTP has only hop-by-hop encryption, which means any MTA on ...


1

Based on the links you've provided, this appears to be CVE-2011-0411. Given a CVE, you can browse at suse.com to see which packages will fix it. In this case, postfix >= 2.5.6-5.6.1 (patchname: slessp1-postfix) will correct the issue for SLES 11.


1

No. It only protects the email in transit. Typically, you need to use TLS in two places. Firstly between the two email servers and secondly between the client and their email server. Trust in the contents of an email is a different matter though clearly if someone has gone to the trouble of ensuring an end-to-end encrypted channel, they are likely to ...


1

It depends. Basically you have the choice to: Always require a valid certificate. This obviously means you have to disable fallback to plaintext and enforce TLS use. This will prevent some servers and the people using them from sending you mail. If you can't enforce to use TLS, it doesn't make any sense to enforce a valid certificate. A encrypted ...


1

Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS? It can be, if used correctly. When using FTP, for example, your client can inform you whether TLS is used and with which certificate. This places a burden on the client to check the security of the connection, similar when browsing HTTPS sites. In ...


1

Well, the main idea is to "not reinvent the wheel": the standard protocol already have it's port number specifically standardized. Do you need a higher security level? - you're welcome! Enable STARTTLS and be as secure as you wish, because it is not restricted in security enhancement it brings. Do not feel so comfortable staying fully backwards compatible? - ...


1

Yes rfc5321 section 3.7.2 says: The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies so, a mail server may not provide the "with clause" (this is even more clear in the ANTLR of section 4.4, see Opt-info), in which case you have no data …but if it specifies that the transport was ...


1

I don't think client certificates will solve the problem of computational DoS. Consider the sequence of messages in SSL / TLS: The client certificate is sent to the server after the ServerKeyExchange message. In the case of [EC]DHE_RSA the ServerKeyExchange message involves the server signing the DH parameters with it's long term public key. So the server ...


1

It is important to notice that there is a big difference between public SMTP senders (that can use port 25 and send unencrypted content) and client's submission that is used for authentication and secure client-server content transfer. I prefer not to rely on public senders paranoid and security level, however always think about domain users security and ...


1

Regarding encryption, your postfix and dovecot configuration was fine enough to send and receive email, especially encryption-related configuration. Your SSL configuration was safe enough to secure the email transportation when travel from and to your server. Anyway, in the question you don't specify how your MTA handle mail client. For that, you should ...


Only top voted, non community-wiki answers of a minimum length are eligible