Re: Anyone use this email server configuration ?
* Viktor Dukhovni postfix-users@postfix.org: On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. The blog recommends at least one of smtp[d]_tls_loglevel = 2, this is unwise except when debugging. On a low traffic server? -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Anyone use this email server configuration ?
On Thu, Sep 12, 2013 at 03:36:30PM +0200, Ralf Hildebrandt wrote: The blog recommends at least one of smtp[d]_tls_loglevel = 2, this is unwise except when debugging. On a low traffic server? Even on a low traffic server the voluminous TLS logging just obfuscates the useful content in the logs. -- Viktor.
Re: Anyone use this email server configuration ?
* Frank Bonnet frank.bon...@esiee.fr: Hello Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. With opportunistic TLS, reducing the set of ciphers available always reduces security, since when the handshake fails mail is subsequently sent in the clear. The Postfix SMTP client and server cipherlists are *ordered* sensibly, and with SSLv2 disabled (default), there should be no downgrade attacks. It only makes sense to restrict the cipherlist to a more secure subset when TLS is mandatory. The default cipher grade for mandatory TLS is medium. The medium grade is essentially just 128-bit RC4: AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 so if not using RC4 is a requirement, raising the mandatory grade to high can be tried with care, but the effect is not always necessarily for the better: $ posttls-finger -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) $ posttls-finger -c -L summary -g high gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits) So with medium you get RC4 with PFS, and with high you get AES128 without PFS. Which is better, we don't know for sure. On a related note, in the Postfix SMTP client, I'd like at some point to disable not only SSLv2, but also SSLv3, leaving only TLSv1 and up enabled. This ensures that TLSv1 extensions are sent in the SSL client HELO message. Extensions can signal the list of supported EECDH curves, support for session tickets, ... The right time for this would probably be after OpenSSL 1.0.2 is released, because then with an appropriate small change to Postfix, the best EECDH curve can be negotiated, rather than fixed by the server. SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote: SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? The BEAST, CRIME, ... attacks are HTTPS specific, and do not generally apply to other TLS applications, in particular they are not relevant to SMTP. One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? SMTP servers don't know whether the client is doing opportunistic TLS or authenticating the server. They should generally allow all ciphersuites on port 25 (they can if desired switch from client cipher order to server cipher order). Shrinking the server cipherlist increases the odds of plaintext re-transmission with little gain. Port 25 TLS security is in the hands of the client. On 587, servers can be more selective. We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. May do the same for outgoing connections. This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. The blog recommends at least one of smtp[d]_tls_loglevel = 2, this is unwise except when debugging. -- Viktor.
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 16:34, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. With opportunistic TLS, reducing the set of ciphers available always reduces security, since when the handshake fails mail is subsequently sent in the clear. The Postfix SMTP client and server cipherlists are *ordered* sensibly, and with SSLv2 disabled (default), there should be no downgrade attacks. It only makes sense to restrict the cipherlist to a more secure subset when TLS is mandatory. The default cipher grade for mandatory TLS is medium. The medium grade is essentially just 128-bit RC4: AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 so if not using RC4 is a requirement, raising the mandatory grade to high can be tried with care, but the effect is not always necessarily for the better: $ posttls-finger -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) $ posttls-finger -c -L summary -g high gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits) So with medium you get RC4 with PFS, and with high you get AES128 without PFS. Which is better, we don't know for sure. On a related note, in the Postfix SMTP client, I'd like at some point to disable not only SSLv2, but also SSLv3, leaving only TLSv1 and up enabled. This ensures that TLSv1 extensions are sent in the SSL client HELO message. Extensions can signal the list of supported EECDH curves, support for session tickets, ... The right time for this would probably be after OpenSSL 1.0.2 is released, because then with an appropriate small change to Postfix, the best EECDH curve can be negotiated, rather than fixed by the server. SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. Will see if that causes any trouble with the few big senders that seem to be stuck on SSLv3/RC4-MD5. May do the same for outgoing connections. Google seems to be only major user of 'ECDHE-RSA-RC4-SHA' at the moment, by the way, not seen that anywhere else. And the AES based ciphers make up the vast majority of connections seen. Mvg, Joni
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote: This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. It rejects the systems that only support SSLv3, does it not? Or am I understanding it incorrectly? The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Forcing the traffic to be sent clear-text is not an improvement. People also have a false sense of security about mail they send in the clear. Pedantry is counter-productive in security. Think about the practical results of proposed policy changes. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. There is little to gain by breaking TLS from those 5 servers unless they are spammers, and you would reject their traffic anyway. In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. That's a very old problem! Historically the Microsoft systems with this problem selected RC4 in preference to 3DES. I am surprised to hear that the problem is still not fixed, and that the server selected 3DES. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Yes, current Exim on Debian squeeze (6.0) or stale Exim (before 4.80-3) on Debian wheezy (7.x). The road to hell is paved with good intentions. In this case one of the Debian maintainers wanted to improve Exim security, as a result of which a lot more mail was sent in the clear as Exim TLS stopped interoperating with most other MTAs. Avoid counter-productive knee-jerk designs. If you want better email security, consider deploying to DNSSEC and publishing DANE TLSA RRs. When you deploy Postfix 2.11, consider making dane the default client TLS security level: smtp_dns_support_level = dnssec smtp_tls_security_level = dane With DANE you take advantage of ECDSA self-signed certificates in parallel with RSA self-signed certificates. Clients that support EECDH and ECDSA will be able to authenticate your server via stronger high-performance public keys and DH groups. At some point in the not too distant future there will be specifications for new EC curves with TLS that are not tainted by the mystery seeds of the NIST curves, making use of these will require OpenSSL 1.0.2 or later, so it will be some time before the state of the art moves beyond what is best-practice today. Stay tuned, but don't expect things to get much better very fast. -- Viktor.
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 17:24, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote: SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? The BEAST, CRIME, ... attacks are HTTPS specific, and do not generally apply to other TLS applications, in particular they are not relevant to SMTP. Ah, I thought I had read that it affected other applications as well, must have misunderstood, thanks. One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? SMTP servers don't know whether the client is doing opportunistic TLS or authenticating the server. They should generally allow all ciphersuites on port 25 (they can if desired switch from client cipher order to server cipher order). Shrinking the server cipherlist increases the odds of plaintext re-transmission with little gain. Port 25 TLS security is in the hands of the client. On 587, servers can be more selective. We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. It rejects the systems that only support SSLv3, does it not? Or am I understanding it incorrectly? The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. It may simply turn out to be misguided paranoia, however ;-) May do the same for outgoing connections. This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? I'll have a look, I only checked for incoming connections yesterday. In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Mvg, Joni
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 10:03:52PM +0200, DTNX Postmaster wrote: The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. In our own case though this is with current software, a direct connection without firewall tomfoolery and whatnot. I shall see if their support department can explain it to me and satisfy my curiosity as to what causes the difference. One thing too keep in mind is that in many cases servers honour client cipher preferences. When your SMTP client connects to their server the cipher-suite chosen is the highest on your preference list that they support. When their client connects to your server the cipher-suite chosen is the highest on their preference list that you support. The two cipher-suites need not be the same even with the same software on their side sending and receiving. http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote: This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't be surprised if that means they are using the same brand of security product. For many large organizations inbound and outbound email are handled by completely separate infrastructure. Inbound mail is often first received by various anti-spam appliances. Outbound mail often bypasses these, and for bulk transactional mail, may be handled by other appliances that handle deliverability tracking, ... The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. Re-enabled SSLv3 for incoming connections again, by the way; turns out that about half of those incoming connections are from an outsourcing firm that handles payment notifications for, yes, another Dutch bank. Sigh ;-) As I mentioned, at this time, deprecating SSLv3 is most likely counter-productive. I am hoping that in a couple of years it will be a practical default for the SMTP client only, where you can define exceptions for problem destinations via smtp_tls_policy_maps. A polite note to their postmaster linking to this thread may encourage them to start making plans to upgrade to inbound systems that can support TLSv1 and up (strictly speaking the STARTTLS EHLO response in SMTP promises support of TLS an IETF standard, not SSLv3). -- Viktor.
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 21:37, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote: The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Forcing the traffic to be sent clear-text is not an improvement. People also have a false sense of security about mail they send in the clear. Pedantry is counter-productive in security. Think about the practical results of proposed policy changes. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. There is little to gain by breaking TLS from those 5 servers unless they are spammers, and you would reject their traffic anyway. Aye, true. Change has been reversed. Misguided paranoia ;-) I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. That's a very old problem! Historically the Microsoft systems with this problem selected RC4 in preference to 3DES. I am surprised to hear that the problem is still not fixed, and that the server selected 3DES. It is possible to install AES extensions on Windows 2003 servers and upgrade the encryption support that way, but given that this server is the last Exchange 2003 server we have to support, on its way out, and Microsoft gives you a gazillion warnings, we decided that it was just not worth the hassle. Supposedly you can disable that particular cipher via registry settings, too, but that didn't work either. In other words, after spending two hours trying to figure out where it was going wrong, we decided that all parties involved would be better off speeding up migration to the new Exchange server instead. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Yes, current Exim on Debian squeeze (6.0) or stale Exim (before 4.80-3) on Debian wheezy (7.x). The road to hell is paved with good intentions. In this case one of the Debian maintainers wanted to improve Exim security, as a result of which a lot more mail was sent in the clear as Exim TLS stopped interoperating with most other MTAs. We generally love Debian, but sadly, these things are one of the drawbacks of using the distribution. They too are misguided at times, heh :-( We haven't seen the issue yet, though, so perhaps we'll stay lucky and be able to avoid the workaround for it. Avoid counter-productive knee-jerk designs. If you want better email security, consider deploying to DNSSEC and publishing DANE TLSA RRs. When you deploy Postfix 2.11, consider making dane the default client TLS security level: smtp_dns_support_level = dnssec smtp_tls_security_level = dane With DANE you take advantage of ECDSA self-signed certificates in parallel with RSA self-signed certificates. Clients that support EECDH and ECDSA will be able to authenticate your server via stronger high-performance public keys and DH groups. At some point in the not too distant future there will be specifications for new EC curves with TLS that are not tainted by the mystery seeds of the NIST curves, making use of these will require OpenSSL 1.0.2 or later, so it will be some time before the state of the art moves beyond what is best-practice today. Stay tuned, but don't expect things to get much better very fast. I will keep it in mind. Thanks for the valuable feedback, Victor :-) Mvg, Joni
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 21:52, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote: This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't be surprised if that means they are using the same brand of security product. For many large organizations inbound and outbound email are handled by completely separate infrastructure. Inbound mail is often first received by various anti-spam appliances. Outbound mail often bypasses these, and for bulk transactional mail, may be handled by other appliances that handle deliverability tracking, ... Ahh, yes. It's the same IP address, but that could just as well be the firewall itself that fronts multiple devices. The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. In our own case though this is with current software, a direct connection without firewall tomfoolery and whatnot. I shall see if their support department can explain it to me and satisfy my curiosity as to what causes the difference. Re-enabled SSLv3 for incoming connections again, by the way; turns out that about half of those incoming connections are from an outsourcing firm that handles payment notifications for, yes, another Dutch bank. Sigh ;-) As I mentioned, at this time, deprecating SSLv3 is most likely counter-productive. I am hoping that in a couple of years it will be a practical default for the SMTP client only, where you can define exceptions for problem destinations via smtp_tls_policy_maps. A polite note to their postmaster linking to this thread may encourage them to start making plans to upgrade to inbound systems that can support TLSv1 and up (strictly speaking the STARTTLS EHLO response in SMTP promises support of TLS an IETF standard, not SSLv3). Noted. In our experience however the postmaster account rarely works, and if it does you run into a mess of red tape where even the most simple change requires multiple signatures, several hours of consulting billed and whatnot. Mvg, Joni
Re: Anyone use this email server configuration ?
On Sep 2, 2013, at 23:13, LuKreme krem...@kreme.com wrote: For servers? Encrypting the drive on a always-on server seems a bit pointless. Once the machine is up and running, the drive is, as you said, unencrypted. However, if someone comes in to seize the machines, they will have to power them off and then the contents of the drives are protected. Not true. For servers with redundant power supplies, one just swaps in a UPS one power lead at a time. For servers with a single PSU, you can splice in power from a UPS, and still move the server without powering it down. Once they have direct access, you are pretty much fooked. And when it concerned No Such Agency, you might be fooked regardless if you're targeted directly. So in terms of 'NSA proofing' your e-mail server, all you can do as a server administrator is what you should have been doing already. Mvg, Joni
Anyone use this email server configuration ?
Hello Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ Thank you
Re: Anyone use this email server configuration ?
FWIW, I seen the url and stopped there. there is literally no way to NSA-proof your email for a number of reasons: First, email is sent cleartext. Even if you authenticate to send and you authenticate to receive, it's going through servers cleartext. A tap before your server is all it would take. Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers. Encrypting individual emails will not be enough. On 9/2/2013 9:06 AM, Frank Bonnet wrote: Hello Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ Thank you -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. Sent from my Toaster (tm).
Re: Anyone use this email server configuration ?
The only way to nsa proof is to encrypt end to end with pgp. I run postfix with gpg-mailgate. All incoming mail is encrypted with that users public key as it comes in for any mail that is not already encrypted client side using pgp. Bruce. -- Please use PGP, ENCRYPT everything. For information about acquiring a secryption.com account, email me. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.12 (GNU/Linux) mQINBFIjp+0BEACohL2HkOtWdsFyR+PUltMawCIfXgo4JWYElCLKWSRdwy8H+z2/ PmwHS2YMsNB5GX+jbv0m3EMJlqCZBRKXISeczFKSj/2Fit7vgplrimdYDtvy3vIN MpLObFyrB3CS81OuFDyxQV7SXt4pCcfnt7b9Vg2Y3XHB38jK9YEMyGp95JW6pY82 /OvGkEs3EDTpv5uS8rzlxSJQH0jWhw0Fxmh3bH248J6EXJswxw/wIl++3fGTwY9V G+pHRTiXB5iQkE9HpkZtAdkIHVW9s2APNDpwCCJUxvP4TY0qbGaYWzAoSIPZQHXY iWv+JTOBZ9boZREZggoxNwn7By3C9zQhB6SIr0P1vZ8RD0LYcWJ5+X34Vw7BVGzD +KXduqQ7ILjA8y1Ns9UgGsQ3RxEWsMehFoCkBfLpeAopm6Xk0ktBn/YSdCrUwc1k IAUd2KFUTJrW48rPzbZd03ogqoMM2QE94VWjI3RCoBgc4amWQDlxHLqsmO22qe13 FgObJQUNBv43zMgTvHkowxBCrlxvDYnHnh7GK4h3mn5WihsexAv1fMeTNAEWO5gt ZO47dCpq/mlArFFnTnQIJsMf7wp6nub/H83ByQNCaBxXG82VEtkTGh2x3I1TENP7 zNhOTCK1BDVHWCjyx0Le53nVnRt6I/yBqFDxHFkNvo0NeQo28ovHghbPOQARAQAB tDRCcnVjZSBNYXJrZXkgKFNlY3J5cHRpb24uY29tKSA8YnJ1Y2VAc2VjcnlwdGlv bi5jb20+iQI4BBMBAgAiBQJSI6ftAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX gAAKCRDIVcS4Lgc6WLfMD/9KXmF9KDUrQ9yRZ/YSsrppr1yZa+ykY9cnKBYsiS/U RZdZL7UhYF+zThPPVFBJPTua9OHbL53Famy5IfDuNiTTiMre0RZer2f3Me0zJJvP sxnqbAFsOlhMpznpUK7kISutfor+fu8KezI9v8gZB8OLUp+c1LNYFHa+ACnY16NM VCtfwkU9et+JykgK0Xc3E8ff5zP4hWtNeKRAaRqUsyipFjsOjbaN4i0nO6edoz/4 Y0Euyolzz9llP7HBfTmg/oHLSAqprnGzw8hRtYiUFqZyHRFgPIi1BgUNTAg6czEU PZcv0zxbdAFOeE21LtC0ElA9WCPPjltRcJsTvfOUkepd2v3fmY8uUKL3HHAg7FzX KtlOx+w5svdyKgJEmFM3aYsZKVQvuFH0Jq7vbB5+BqFj8iq2Rj8guvcNwLOzIQF0 R/CNgTWDzmYNO03+bVqveBPnNlFL5MsGL7A2JwW7tesxvepnQUWv+a9qT7SU+TxB n0ez9VY/4FlcQndoiraRu7Mt6HSvUM6SQFc07RrR/SINOrRVnkbY16On9fKSr7u1 Dfiqlk+6RjJg3GFJ6iOf3oHV3FQ1aw+X4oaDx4XclqOejp8J+HETSTh9soKGG1sR CPs2eRfIfFjLn5TfkiWS0t4NovCEHgFbgo+XLuvHvzh/sTCyTMD9Jr6+KO/ZB/RH PbkCDQRSI6ftARAA4/FeX0a1kCHYoRtp9TEzASTzplVddX8Tv3Ha7aigA71BBVB5 jGZj/bFg0XWOSjAZxpl27rqyGQTqomNnX11Nn1+RC0tle4uJnh97qs7ot4vJfzfO S7GBxFHBTzd+EJnVFHeJJZTHsp51VqI9YFaNFDjms2TUTFQ54SOE0fE9/Q3///Hh LqF8lJFmwVi/OMSxmyrf4Q9aDoo3QKL4zX3o2OP3m1F92ltMyphZTPYwamPwu765 0nr6rDwYnEQeFSa3SmA1eUT+bKSkZ7TUm/OBJyt8RK+hjNou+epV5IsREcApe2Px BWwNOVx7oYM8seM87QGFe1iXuD+qrlU1JUsoZDTqovVqE1lBxm7UzlcyH3AkJnbh GTbt/DvGYOo1d4pYbtjbrgM3+kFckmgP/DYPJE9ukbbWwpFEiC5AMkPKiSNKqxd7 U7xgmnpM5nfBbYO3/sPAv6QZvJTtKdnWrN8aOU0iuyHx07JYY0WjYqjc6+0PD9zi 5LAs86PqC984/wll8QyxntpnDuasm3gzsllU+or7CEZXtJnkGqHZY3t4PBszH0rF 7QC5JHNHNI9YuwUfRKj93H04RhB9FOOUJJsV4PJSjlSEt4GjwPGWmzI2DgXXag0x ZIrzcZ6YxKrQsj/vu/yh/1yUfHzKZnqpQhuoZqGn2RqDKurBz4f86z5HcsUAEQEA AYkCHwQYAQIACQUCUiOn7QIbDAAKCRDIVcS4Lgc6WNLdD/46JABUVO2KnwrgErQV idTfdGh0jQE5K4BiLCKTjXsNEHvaKilfbU6kW/3fb9GrNS/VmTMqn30zjw80Y4ga 1j2i3vi8yUZhl65pxh+sIsPE25fBvFIR+mnI1s6sHkCEMSVKBuSe4XskxQV4hwCW P7kh/W9jpCv1tGW681SqUFsCqvPHGnNJeX8vDugh+X9EJGst/EmRHcFumP8BcMiK aoqbS3qQNGhA6UoZMY7CH9DysbcTG59ABAv24dq2fDuZdVIFEVsNGYPorA6QIeC9 el+MD+WtSlA2+g9a6cUp6UX1ba765B2rYJrtXqHxepJFw63KqJzRUdXZ9zs+XrXn GmfCQ1fb3+4fPYqvObFDYQXr7EayacIOlu8ctbRQqCibvWX/ECJm5vpwWgfZPkJz Ms5t9FJM7ShrUw8dW0TPD7IdUk92GnEj+ZiuQjOMbkunpcHH8fDT/fwYY44exmaS oJPsGpoO+TtUFMcMDvYcaPBlxy9e4JWGxAp8pWPBtb5ZW7wFgRXHYBRLD+Pr/q3+ 5lcS7Mhy5lztq654s4d37nZfRMbnm46kvDk9zSvLERm+WK6maTWmTVMvqHNxvYot UWhPgy6CzbAcz91UiGa6lL6ky1OE+ZUT41ZZu9BVCdNBYSo2K4aQY/PdMbzcQhzN evN13R2qLKotuTlIA9Im7lJZqw== =q1E0 -END PGP PUBLIC KEY BLOCK-
Re: Anyone use this email server configuration ?
On 9/2/2013 9:35 AM, Bruce Markey wrote: The only way to nsa proof is to encrypt end to end with pgp. I run postfix with gpg-mailgate. All incoming mail is encrypted with that users public key as it comes in for any mail that is not already encrypted client side using pgp. This makes sense, but this still isn't secure. Even if you use TLS from endpoint to endpoint, mail is usually sent through multiple servers until it gets to that point. You can send mail through your own server, but it can not be encrypted when you send it out to another server, which pretty much breaks any concept of NSA-proof email. Bruce. -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. Sent from my Toaster (tm).
Re: Anyone use this email server configuration ?
On 2013-09-02 Littlefield, Tyler wrote: On 9/2/2013 9:35 AM, Bruce Markey wrote: The only way to nsa proof is to encrypt end to end with pgp. ^^^ I run postfix with gpg-mailgate. All incoming mail is encrypted with that users public key as it comes in for any mail that is not already encrypted client side using pgp. This makes sense, but this still isn't secure. Even if you use TLS from endpoint to endpoint, mail is usually sent through multiple servers until it gets to that point. You can send mail through your own server, but it can not be encrypted when you send it out to another server, which pretty much breaks any concept of NSA-proof email. Read again. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Anyone use this email server configuration ?
On Sep 2, 2013, at 17:43, Ansgar Wiechers li...@planetcobalt.net wrote: On 2013-09-02 Littlefield, Tyler wrote: On 9/2/2013 9:35 AM, Bruce Markey wrote: The only way to nsa proof is to encrypt end to end with pgp. ^^^ I run postfix with gpg-mailgate. All incoming mail is encrypted with that users public key as it comes in for any mail that is not already encrypted client side using pgp. This makes sense, but this still isn't secure. Even if you use TLS from endpoint to endpoint, mail is usually sent through multiple servers until it gets to that point. You can send mail through your own server, but it can not be encrypted when you send it out to another server, which pretty much breaks any concept of NSA-proof email. Read again. He makes the wrong point, but is partly right; PGP encrypts the content of the message only, and not the metadata contained in the headers. And that metadata can show very interesting patterns, patterns that sometimes tell you more than the content of the messages themselves. Mvg, Joni
Re: Anyone use this email server configuration ?
On 02 Sep 2013, at 07:10 , Littlefield, Tyler ty...@tysdomain.com wrote: Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers. Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. I suspect it's more difficult in linux/freebsd, but I bet not much more than trivial. -- You could save people. You could get there in the nick of time. And something could snap its fingers and say, no , it has to be that way. Let me tell you how it has to be. This is how the legend goes. --Soul Music
Re: Anyone use this email server configuration ?
Top-posting this once. This is obnoxious. Stop it. On 02 Sep 2013, at 07:35 , Bruce Markey br...@secryption.com wrote: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.12 (GNU/Linux) mQINBFIjp+0BEACohL2HkOtWdsFyR+PUltMawCIfXgo4JWYElCLKWSRdwy8H+z2/ PmwHS2YMsNB5GX+jbv0m3EMJlqCZBRKXISeczFKSj/2Fit7vgplrimdYDtvy3vIN MpLObFyrB3CS81OuFDyxQV7SXt4pCcfnt7b9Vg2Y3XHB38jK9YEMyGp95JW6pY82 /OvGkEs3EDTpv5uS8rzlxSJQH0jWhw0Fxmh3bH248J6EXJswxw/wIl++3fGTwY9V G+pHRTiXB5iQkE9HpkZtAdkIHVW9s2APNDpwCCJUxvP4TY0qbGaYWzAoSIPZQHXY iWv+JTOBZ9boZREZggoxNwn7By3C9zQhB6SIr0P1vZ8RD0LYcWJ5+X34Vw7BVGzD +KXduqQ7ILjA8y1Ns9UgGsQ3RxEWsMehFoCkBfLpeAopm6Xk0ktBn/YSdCrUwc1k IAUd2KFUTJrW48rPzbZd03ogqoMM2QE94VWjI3RCoBgc4amWQDlxHLqsmO22qe13 FgObJQUNBv43zMgTvHkowxBCrlxvDYnHnh7GK4h3mn5WihsexAv1fMeTNAEWO5gt ZO47dCpq/mlArFFnTnQIJsMf7wp6nub/H83ByQNCaBxXG82VEtkTGh2x3I1TENP7 zNhOTCK1BDVHWCjyx0Le53nVnRt6I/yBqFDxHFkNvo0NeQo28ovHghbPOQARAQAB tDRCcnVjZSBNYXJrZXkgKFNlY3J5cHRpb24uY29tKSA8YnJ1Y2VAc2VjcnlwdGlv bi5jb20+iQI4BBMBAgAiBQJSI6ftAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX gAAKCRDIVcS4Lgc6WLfMD/9KXmF9KDUrQ9yRZ/YSsrppr1yZa+ykY9cnKBYsiS/U RZdZL7UhYF+zThPPVFBJPTua9OHbL53Famy5IfDuNiTTiMre0RZer2f3Me0zJJvP sxnqbAFsOlhMpznpUK7kISutfor+fu8KezI9v8gZB8OLUp+c1LNYFHa+ACnY16NM VCtfwkU9et+JykgK0Xc3E8ff5zP4hWtNeKRAaRqUsyipFjsOjbaN4i0nO6edoz/4 Y0Euyolzz9llP7HBfTmg/oHLSAqprnGzw8hRtYiUFqZyHRFgPIi1BgUNTAg6czEU PZcv0zxbdAFOeE21LtC0ElA9WCPPjltRcJsTvfOUkepd2v3fmY8uUKL3HHAg7FzX KtlOx+w5svdyKgJEmFM3aYsZKVQvuFH0Jq7vbB5+BqFj8iq2Rj8guvcNwLOzIQF0 R/CNgTWDzmYNO03+bVqveBPnNlFL5MsGL7A2JwW7tesxvepnQUWv+a9qT7SU+TxB n0ez9VY/4FlcQndoiraRu7Mt6HSvUM6SQFc07RrR/SINOrRVnkbY16On9fKSr7u1 Dfiqlk+6RjJg3GFJ6iOf3oHV3FQ1aw+X4oaDx4XclqOejp8J+HETSTh9soKGG1sR CPs2eRfIfFjLn5TfkiWS0t4NovCEHgFbgo+XLuvHvzh/sTCyTMD9Jr6+KO/ZB/RH PbkCDQRSI6ftARAA4/FeX0a1kCHYoRtp9TEzASTzplVddX8Tv3Ha7aigA71BBVB5 jGZj/bFg0XWOSjAZxpl27rqyGQTqomNnX11Nn1+RC0tle4uJnh97qs7ot4vJfzfO S7GBxFHBTzd+EJnVFHeJJZTHsp51VqI9YFaNFDjms2TUTFQ54SOE0fE9/Q3///Hh LqF8lJFmwVi/OMSxmyrf4Q9aDoo3QKL4zX3o2OP3m1F92ltMyphZTPYwamPwu765 0nr6rDwYnEQeFSa3SmA1eUT+bKSkZ7TUm/OBJyt8RK+hjNou+epV5IsREcApe2Px BWwNOVx7oYM8seM87QGFe1iXuD+qrlU1JUsoZDTqovVqE1lBxm7UzlcyH3AkJnbh GTbt/DvGYOo1d4pYbtjbrgM3+kFckmgP/DYPJE9ukbbWwpFEiC5AMkPKiSNKqxd7 U7xgmnpM5nfBbYO3/sPAv6QZvJTtKdnWrN8aOU0iuyHx07JYY0WjYqjc6+0PD9zi 5LAs86PqC984/wll8QyxntpnDuasm3gzsllU+or7CEZXtJnkGqHZY3t4PBszH0rF 7QC5JHNHNI9YuwUfRKj93H04RhB9FOOUJJsV4PJSjlSEt4GjwPGWmzI2DgXXag0x ZIrzcZ6YxKrQsj/vu/yh/1yUfHzKZnqpQhuoZqGn2RqDKurBz4f86z5HcsUAEQEA AYkCHwQYAQIACQUCUiOn7QIbDAAKCRDIVcS4Lgc6WNLdD/46JABUVO2KnwrgErQV idTfdGh0jQE5K4BiLCKTjXsNEHvaKilfbU6kW/3fb9GrNS/VmTMqn30zjw80Y4ga 1j2i3vi8yUZhl65pxh+sIsPE25fBvFIR+mnI1s6sHkCEMSVKBuSe4XskxQV4hwCW P7kh/W9jpCv1tGW681SqUFsCqvPHGnNJeX8vDugh+X9EJGst/EmRHcFumP8BcMiK aoqbS3qQNGhA6UoZMY7CH9DysbcTG59ABAv24dq2fDuZdVIFEVsNGYPorA6QIeC9 el+MD+WtSlA2+g9a6cUp6UX1ba765B2rYJrtXqHxepJFw63KqJzRUdXZ9zs+XrXn GmfCQ1fb3+4fPYqvObFDYQXr7EayacIOlu8ctbRQqCibvWX/ECJm5vpwWgfZPkJz Ms5t9FJM7ShrUw8dW0TPD7IdUk92GnEj+ZiuQjOMbkunpcHH8fDT/fwYY44exmaS oJPsGpoO+TtUFMcMDvYcaPBlxy9e4JWGxAp8pWPBtb5ZW7wFgRXHYBRLD+Pr/q3+ 5lcS7Mhy5lztq654s4d37nZfRMbnm46kvDk9zSvLERm+WK6maTWmTVMvqHNxvYot UWhPgy6CzbAcz91UiGa6lL6ky1OE+ZUT41ZZu9BVCdNBYSo2K4aQY/PdMbzcQhzN evN13R2qLKotuTlIA9Im7lJZqw== =q1E0 -END PGP PUBLIC KEY BLOCK- -- For more than a thousand generations the Jedi were the guardians of peace and justice in the galaxy. Before the dark times. Before the Empire.
Re: Anyone use this email server configuration ?
Am 02.09.2013 22:55, schrieb LuKreme: On 02 Sep 2013, at 07:10 , Littlefield, Tyler ty...@tysdomain.com wrote: Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers. Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. and after that? I suspect it's more difficult in linux/freebsd, but I bet not much more than trivial it is trivial on *every* OS but it does help you *nothing* in reality it does help you only if someone takes oyur hardware and is running in *any* other case the encrypted disk is unlocked and any intrusion has the same success as for an unencrypted devive so why do people insist claim encrypted drives gain any security if they are not talking about notebooks stolen in a cafe?
Re: Anyone use this email server configuration ?
On 02 Sep 2013, at 15:02 , li...@rhsoft.net wrote: Am 02.09.2013 22:55, schrieb LuKreme: On 02 Sep 2013, at 07:10 , Littlefield, Tyler ty...@tysdomain.com wrote: Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers. Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. and after that? I was making no point about the securing of mail, just about encrypting the hard drive. it does help you *nothing* in reality Um... no, that's not right. Encrypting drives is quite useful. it does help you only if someone takes oyur hardware and is running in *any* other case the encrypted disk is unlocked and any intrusion has the same success as for an unencrypted devive No, when I have my laptop the drive is encrypted until one of the users authorized to unencrypted the drive logs in, or enters their password to wake the machine from sleep. so why do people insist claim encrypted drives gain any security if they are not talking about notebooks stolen in a cafe? For servers? Encrypting the drive on a always-on server seems a bit pointless. Once the machine is up and running, the drive is, as you said, unencrypted. However, if someone comes in to seize the machines, they will have to power them off and then the contents of the drives are protected. -- I can't see the point in the theatre. All that sex and violence. I get enough of that at home. Apart from the sex, of course. - Baldrick - Sense and Senility
Re: Anyone use this email server configuration ?
Am 02.09.2013 23:13, schrieb LuKreme: On 02 Sep 2013, at 15:02 , li...@rhsoft.net wrote: Am 02.09.2013 22:55, schrieb LuKreme: On 02 Sep 2013, at 07:10 , Littlefield, Tyler ty...@tysdomain.com wrote: Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers. Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. and after that? I was making no point about the securing of mail, just about encrypting the hard drive. it does help you *nothing* in reality Um... no, that's not right. Encrypting drives is quite useful. without *context* *nothing* is useful so why do people insist claim encrypted drives gain any security if they are not talking about notebooks stolen in a cafe? For servers? Encrypting the drive on a always-on server seems a bit pointless interesting argument on a *server list*
