Tag Info

Hot answers tagged

16

Yes, it is still a bad idea. Three reasons: While the RFC you cited (RFC 2487) is in fact obsoleted by the current standard RFC 3207, the current standard keeps the MUST NOT verbiage you quoted in your question. SMTP Clients are not required to implement STARTTLS. It is totally acceptable not to do so. While STARTTLS is becoming more common, it is ...


15

There is no difference in the security between the two options. SSL/TLS opens an SSL/TLS connection first, then begins the SMTP transaction. This must occur on a port that does not have a non-SSL/TLS SMTP server already running; it is impossible to configure a single port to handle both plain text and encrypted connections due to the nature of the ...


11

The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is: STARTTLS is less secure than TLS. Instead of doing the talking myself, I will allow the RFC to speak for itself, with the four relevant bits highlighted in BOLD: A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the ...


8

Don't bother with sniffing the network connection; as @voretaq7 explained, you can't. Instead, have postfix log the connection by adding the IP address of the remote SMTP server to debug_peer_list. And if that doesn't get you enough detail to understand what's going on, you can set smtp_tls_loglevel 4 to get a complete dump of everything that went over the ...


6

Check your logs. (Or run the OpenLDAP clients in Verbose mode and they will tell you if they're using SSL.) Don't trust your logs/clients. (Run wireshark or something similar and verify the traffic.)


6

This is an old question, but I wanted to add an updated answer for anyone searching and finding this, but using a more modern version of ejabberd (14.12 at the time of this writing). The following options (in the new YAML configuration format) should make starttls required, change the ciphers list to something decent, and disable legacy SSL support for s2s ...


6

Google maintains open statistics on their percentage of mail that is encrypted, both inbound and outbound. This information should be extremely useful to you in determining whether this is worth implementing: http://www.google.com/transparencyreport/saferemail/


5

Allow me to rephrase your question: I want to stick something in the middle of an TLS-encrypted connection that shows me the cleartext that's being sent. . . . Well it wouldn't be very secure now, would it? I mean the whole point of TLS is to prevent exactly what you're trying to do! -- So no, what you're asking for is NOT possible, nor is it ...


5

You can use smtp_tls_policy_maps to configure the TLS policy on a per host basis. main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/postfix/tls_policy: mailhost.com encrypt Remember to run postmap /etc/postfix/tls_policy after editing that file. You could also set smtp_tls_security_level = may to use TLS when the remote server ...


4

Is it so that once this certificate is accepted, it is impossible to do a man in the middle attack. For somebody to make use of this public self signed SSL certificate they also need a private key that the mail server keeps? That is correct. An attacker cannot fake being the remote server unless they have the private key that matches what the client is ...


4

Enable opportunistic TLS support, i.e. send messages using TLS when the remote server identifies itself as supporting TLS, but send messages in the clear when the remote server does not : # main.cf smtp_tls_security_level = may You have enabled smtpd_tls_security_level=encrypt in your config (only one letter difference), that only covers incoming e-mail ...


4

16:33:19 SMTP REPLY: 250-STARTTLS 16:34:31 SMTP REPLY: 250-XXXXXXXA It looks for me that there is something manipulating the connection, in that it explicitly replaces the announced STARTTLS feature from the server with some junk. This way the client thinks that STARTTLS is not supported and will often downgrade to plain text and thus the ...


3

There are several problems with the transporting email a secure way and this questions might be better asked at security.stackexchange.com. The mail can be intercepted at various stages: Explicit TLS (STARTTLS) and implicit TLS (SMTPS) provide hop-by-hop and not end-to-end security, that is each mail server in between has access to the unencrypted mail. ...


3

You should strongly consider getting a free SSL Cert if you control the domain. There are a couple provides of free certs. The "accepted" cert in Thunderbird pairs the hostname by which you referenced the server with the thumbprint of the certificate. So a MITM attack would be nigh impossible without solving the DL Problem. This assumes you picked a ...


3

Not feasible. HTTP and HTTPS are two distinct services which behave in markedly different ways (despite the naming and payload being similar). Unique services must bind to unique ports to enable client and server to communicate in a language both understand. To accomplish this you would need to have a client that would connect to the port, negotiate which ...


3

Perhaps the rails app doesn't trust the postfix certificate?


3

At the bottom of your config file, you have smtpd_tls_security_level = encrypt, this requires all inbound SMTP clients to use TLS. If the inbound client doesn't support TLS, then the connection will fail. (This seems likely to be the case for gmx.net, given the error message.) If you set smtpd_tls_security_level = may, then you should be able to get email ...


2

Try TLS_REQCERT never in /etc/ldap/ldap.conf. This will prevent checking of the certificate. Note that it makes the connection even less secure. /etc/ldap.conf should not affect ldapsearch(1) Also try dropping the second -Z on the command line. That might be what's forcing the fail even though you have TLS_REQCERT allow.


2

Your test is wrong. You have not given openssl any trusted CAs. Your CApath may vary, but you'll need to issue something like this: openssl s_client -showcerts -connect smtp.domain.tld:465 -CApath /etc/ssl/certs Edit: I gather from your comment that you don't get it, so let's try this again without even bothering with smtp shall we? This will ensure ...


2

From: http://www.postfix.org/TLS_README.html ... Server-side TLS activity logging ... Use log level 3 only in case of problems. more... To get additional information about Postfix SMTP server TLS activity you can increase the log level from 0..4. Each logging level also includes the information that is logged at a lower logging level. Level Postfix ...


2

Google Mail's SMTP server is requiring you to connect with TLS, but you have configured fetchmail to never use TLS. Check your fetchmail command line and configuration file for sslproto and make sure it is set to TLS1. On the command line: --sslproto TLS1 In the conf file: sslproto TLS1 See the fetchmail documentation for more on configuring SSL/TLS. ...


2

What you're wishing for is STARTTLS for HTTP. This is actually proposed by RFC 2817, which was written in what is now Ye Olden Days of Yon Internete. I found some quick references that suggested that both Apache and lighthttpd support this, but further research is disappointing for lighttpd — sorry about that. Here's the documentation for setting it up with ...


2

You have declared that all tls connections must have a strength of 256. You have not declared anything about other types of connections. Perhaps you wanted security minssf=256? man slapd.conf sections sasl-secprops and security for more information.


2

I've not tested this as I use posftix but I've seen in my reading the following: CipherList=HIGH ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 Not sure which version this references but appears you control what ciphers are in use both when sendmail acts as a client ...


2

You have confirmed above that more has changed than merely the IP address: specifically, the new network onto which the VM has been moved is behind a CISCO ASA firewall. Those firewalls do what they describe as "protocol fixup", which in the case of SMTP means messing with the information that's passed at layer 4. By telnetting from your client to the ...


2

In this line: -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject You are rejecting not authenticated messages from submission port. You need change the test, to authenticate (AUTH command) or replace reject to reject_unauth_destination


2

The tools were not lying! The solution have to look this way: # inbound smtpd_tls_security_level = may smtpd_tls_protocols=!SSLv2,!SSLv3 smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3 # outbound smtp_tls_security_level = may smtp_tls_protocols=!SSLv2,!SSLv3 smtp_tls_mandatory_protocols=!SSLv2,!SSLv3 smtp[d]_tls_security_level == "may": ...


2

SMTPS means SMTP over TLS, like with HTTPS. So first a TLS connection is established (without fallback), and then STMP is started. Just as nobody expects HTTPS on the HTTP-Port 80, you should not expect that anybody who connects to your STMP-service sends TLS requests. Thus, all connections to your server on port 25 will likely fail, if you enforce TLS! ...


2

Requiring StartTLS: {s2s_use_starttls, require}. instead of {s2s_use_starttls, true}. (keep in mind this will currently make you unable to connect to gmail.com and all domains they host). Weak ciphers: See http://www.process-one.net/docs/ejabberd/guide_en.html#sec27. I think this means doing something like adding {ciphers, "..."} to the ejabberd_c2s ...


2

Short version: Use TLS_Rcpt access table entries. to specify per recipient's domain requirements. TLS_Rcpt:fooexample.com ENCR:112` Full version: 0) TLS_Clt is for incoming connections. Use TLS_Srv for outgoing connections 1) Sendmail looks for TLS_Srv access table entries based on $&{server_name} first and $&{server_addr} later. 2) ...



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