Suppose your Aunt or Uncle is easily fooled by phishing attempts and their computer has multiple root kits and key loggers running.  Assume their computing habits will never change.  

Looking at his wireless router you can see that he only visits a few dozen or a few hundred websites multiple times in a month.  Instead of trying to keep the bad guys out, set up the firewall's default outbound rule to be block (deny/reject) everything to prevent the bad guys from getting out.

If this non-technical relative had a simple python program running with an ssh connection into the firewall, the program could monitor the IP addresses as they get blocked.  The program would then ask the user if they want to access 72.21.211.176 Amazon.com (USA).  If the user says yes, the program might then ask:  Allow outbound access to all 72.21.. networks?  This is an attempt to save some time creating a whitelist.

I know opinions vary as to the value of egress filtering.  But with all the technology advances in the last 20 years, I find it frustrating that there is not a simple way for non-technical users to prevent sending data to that village in Wales (Llanfairpwllgwyngyll) that we all know is full of nation state hackers.
http://en.wikipedia.org/wiki/Llanfairpwllgwyngyll

Since I am more of a SQL developer than a security expert, I am posting this to see if this would realistically help secure the home network in the example above.  Of course the solution is not perfect, but it seems like it would help.  This thought came about after reading about DGA malware that have been known to create thousands of new domains per second and realizing that attackers are way more sophisticated than I imagined.  http://en.wikipedia.org/wiki/Domain_generation_algorithm

UPDATE
As both answers indicate, this is not a good way to approach the problem.  Too many IPs in the world and the user can't be trusted to allow only safe domains.

You are misreading Bernstein and Lange's advice (admittedly, their presentation is a bit misleading, with the scary red "False" tags). What they mean is not that some curves are inherently unsafe, but that safe implementation of some curves is easier than for others (e.g. with regards to library behaviour when it encounters something which purports to be the encoding of a valid curve point, but is not).

What you really want is a curve such that:


the software which you will entrust with your private key (your SSL server) is properly implemented and will not leak details about your private key;
interoperability will be achieved.


For a SSL server certificate, an "elliptic curve" certificate will be used only with digital signatures (ECDSA algorithm). The server will sign only messages that it generates itself; and, in any case, the only "private" operation involving a curve in ECDSA is multiplication of the conventional base point (hardcoded, since it is part of the curve definition, hence correct) by a random value that the server generates. Therefore, in your use case, there is no risk of private key leakage that would be specific to the used curve. If your SSL implementation is poor, it will be poor for all curves, not for just some of them.

"Interoperability" means that you would probably prefer it if SSL clients can actually connect to your server; otherwise, having a SSL server would be rather pointless. This simplifies the question a lot: in practice, average clients only support two curves, the ones which are designated in so-called NSA Suite B: these are NIST curves P-256 and P-384 (in OpenSSL, they are designated as, respectively, "prime256v1" and "secp384r1"). If you use any other curve, then some widespread Web browsers (e.g. Internet Explorer, Firefox...) will be unable to talk to your server.

Use P-256 to minimize trouble. If you feel that your manhood is threatened by using a 256-bit curve where a 384-bit curve is available, then use P-384: it will increases your computational and network costs (a factor of about 3 for CPU, a few extra dozen bytes on the network) but this is likely to be negligible in practice (in a SSL-powered Web server, the heavy cost is in "Web", not "SSL").
