Tag Info

New answers tagged

1

In practice: No, you need to make sure many other elements of the network aren't fooling you. I will concentrate on the transmission here. First, you want to make sure, you can contact the right recipient’s server. To do that, your sending mail servers does a DNS-Lookup for the MX-Record of the domain. Then the resulting FQDN has to be resolved to get an ...


0

In a perfect world with no untrustworthy people we'd never need any security at all. We don't live in that world, and there's far more people we need to trust than merely administrators and ISPs. Adversaries can range from the NSA armed with National Security Letters, hackers and packet sniffers to skilled attackers using zero day exploits. Rogue admins ...


0

If you are going to rely on STARTTLS (assuming that is what you mean by supporting encryption between servers), the servers will need to be configured to enforce the use of STARTTLS rather than the normal default, which is opportunistic. The opportunistic 'mode' is vulnerable to a man in the middle attack.


0

When your systems are completely save and trustworth you would not need additional encryption. But can you be sure that your systems realy are that save? For example if one of your servers gets hacked or if (as makerofthings7-c-lamont pointed out) your backups are compromised your entire security is broken. When you use something like PGP or S/MIME an ...


1

I would suggest that the lifetime of a key should be determined by its strength, according to both its keysize, and to the likelihood of reports of weaknesses in the algoritm used to create the keys. According to Technet.com in 2009, regarding how long RSA suggest the validity period of a certificate should be, based on how long it would take an adversary ...


3

1: The advantage of S/MIME over PGP is that you sign/encrypt a complete mime entity, not a text. This makes it possible to sign/encrypt a entire message/rfc822. Yes, headers must be visible and changeable to the MTA, but that can be accomplished by taking the WHOLE mail, S/MIME sign or encrypt it, and then package the signed/encrypted S/MIME entity it in a ...


4

I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal ...


4

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem. The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the ...



Top 50 recent answers are included