Given that users need a password to unlock the private key in the id file locally, it seems odd to me that after this the nRPC transport between the notes client and the domino server is in the clear? Can encryption of emails and the windowing code etc be encrypted?
Thanks Stephen, that did the trick. I am surprised it was not encrypted by default. RC4 is fine for us provided the RC4 key is not compromised. I will read more about how this is (a) generated and exchanged, or (b) agreed on before hand… It seems IBM are rather like M$ when it comes to security by default.
Network port encryption is not enabled by default because many customers care more about the slight performance hit than about the risk of a network sniffer.
I should clarify that it is neither the inidividual emails nor the databases themselves that I want encrypted, it is the network traffic (the stream) I can see on my client in the trace popup “network traffic encrypted at the servers request” but when I capture the packets I can read the contents in plain text.Thanks
Check the Administrator help on encrypting network ports. It’s easy to enable. The NRPC traffic will be encrypted so if your users are sitting at a Starbucks with a wireless connection it can’t be eavesdropped. It’s not a true SSL encryption (I believe that’s available in Notes 8) but RC4, which I believe is theoretically breakable but in practice can be considered secure.If you tried enabling this, did you restart the port after doing so? You should not be able to see plain text.
Subject: RC4, SSL, and Notes network port encryption
A few points…
Notes/Domino network port encryption pre-dates SSL by many years.
Only a small portion of the SSL protocol is devoted to negotation of the channel encryption key – the bulk of the cycles for SSL are spent performing one-way authentication of the server (mutual authentication only if client certificate authentication is enabled). This is comparable to the Notes Authentication protocol (which always performs mutual authentication), but without
RC4 can be used for channel encryption with SSL, and is actually the most commonly used algorithm with SSL, because – being a stream cipher – it is much faster than any of the block ciphers at comparable key sizes such as AES or 3DES.
RC4 is only “theoretically breakable” if used incorrectly. Most of the RC4-related security “flaws” that are bandied about are actually due to people who don’t know what they’re doing use a stream cipher as if it were a block cipher, which opens the door to a fairly trivial known plaintext attack.