I disagree. While not a magic "I've added that, now I'm totally secure" the one I have deployed stops many attacks designed to infect old code. I don't have that old code, but if I did the WAF would stop the attacts against it.
Is it perfect? Of course not. Is it another layer of protection, sure it is.
WAFs aren't perfect, no security product is. They do allow you to implement protection against many types of common attacks against your website. This is useful if your site runs applications that you don't have the ability to fix XSS/Injection/etc... issues on (you don't own the code, you don't have resources to do it, etc...). This is actually pretty important as most websites out there run old and/or closed source and/or 3rd party code and/or don't have internal resources to identify and fix every vulnerability 100% of the time. A well tuned WAF provides a decent layer of protection. They also allow you you solve PCI DSS 1.2 Req #6.6 without doing pen testing/vuln testing after every single code change you release.
I think it has a lot to do with making an incredulous statement without providing some evidence, or discussion as to why you think "WAFs are snake oil".
WAFs are usually viewed as relatively useless as they waste time on dumb attacks (specifically blacklisting) that harms more than it helps. Only the stupidest attacks can be caught using WAFs and they are more likely to block legitimate traffic than to help with security.
The idea is similar to using blacklists in filter functions in XSS or SQL protection mechanisms. In theory they could block all malicious but in practice they're poorly written and poorly configured crap that act as more security theatre than anything else. The proper approach is to use context-sensitive whitelists for all client input, not add on layers of what is essentially protocol grep.
And do you really think that's a feasible expectation for the typical shared hosting client -- a business owner with little tech experience who doesn't have the money to hire an actual good developer? The person who doesn't even know that they don't know good developers from bad developers?
>"The proper approach is to use context-sensitive whitelists for all client input, not add on layers of what is essentially protocol grep."
It's regex for HTTP requests / responses. Literally, that's all it does.
>"WAFs are usually viewed as relatively useless as they waste time on dumb attacks (specifically blacklisting) that harms more than it helps. "
By who? References? As I mentioned above, we use WAFs and they help a lot with stupid attacks, because stupid attacks are what most of the attacks are; automated attack crap running on botnets to put up phishing pages on easy targets.
Reasons like....what, exactly? We're a hosting company and we use them on most servers. They're not perfect, but they prevent probably about 95% of the automated attacks that we see come through. If it's enough protection to make them move on to something easier, it's better than nothing. I agree with you that they're pretty easy to bypass, and shame on companies like Barracuda Networks who sell Supermicro servers with CentOS and mod_security and a proxy set up with a fancy web interface and call that a "web application firewall", but they ARE better than nothing.
This is an irresponsible position to take and akin to telling people to "make stronger passwords." It simply isn't realistic. LastPass allows creation of randomly generated passwords very easily and encrypts and stores them so you can use them anywhere. The alternative for most normal users is to create one or two passwords and use them everywhere, compromising the security of all of their accounts. Obviously your response to this would be that they shouldn't do that but the fact is, without something like LastPass, they have little other choice.
This freakout reminds me of the radiation poison bullshit from a few months back. Bananas have radiation therefore bananas are dangerous. Practicality dictates that you are plain wrong.
So, how would you decribe what they've done? They found no trace of any backdoor whatsoever. The few parts that looked funny somehow have been rewritten in a more conservative manner, that's all.
This is actually a bit confusing. My guess is that talloc changed its license at some point.
The ccan version http://ccan.ozlabs.org/info/talloc.html says it is based upon svn://svnanon.samba.org/samba/branches/SAMBA_4_0/source/lib/talloc revision 23158 , and is LGPLv2.
right, because it's not operating on x11 events, it's just directly reading xinput data. there's not much xterm can do when the underlying server is giving away all of the raw input data.
Using /dev/urandom as a password source is fine. It's a CSPRNG. It theoretically degrades if you exhaust entropy, but there's no current attack I know of based on that property. Also, RNG attacks are usually "online", meaning an attacker gets to continually interact with the RNG. This is a one-off offline use. In this scenario, you could probably survive with rand().
Agreed. /dev/urandom should be mixed with other sources of entropy (system statistics, epoch, low-level counters, cryptographic PRNGs like Yarrow) and then "combined" using a cryptographic hash. Such a principle is used in e.g. Fortuna.
Blocking /dev/random when entropy is low is the correct behaviour, but it is a system-dependent behaviour. Darwin (Mac OSX) has the two sources behave identically.
The Darwin man page justifies this behaviour saying:
/dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the
entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected. With
Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either.
and then contradicts itself later by saying:
Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The quality of its output is
however dependent on regular addition of appropriate entropy.
A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys.
On virtual machines, /dev/urandom contains very little if any entropy.
Basically /dev/random takes entropy from the system and feeds it to you.
/dev/urandom is a psudorandom number generator that reseeds from entropy as it gets it. Ie. if it has no entropy, your random numbers are anything but random.
This is a drastic oversimplification. Both urandom and random (on Linux; there's no difference between the two on BSD) are seeded from hard entropy sources. Both urandom and random extract entropy by updating pools with SHA1. The difference is that random has an estimator and will demand more hard entropy when it has serviced too many requests. But it's not as if urandom goes from producing "101010100101000101010100111001" to "111011011110111101111111110111" when entropy is depleted.
In any case, this is entirely irrelevant to the discussion at hand. You can absolutely use /dev/urandom to make a one-shot crypto key. You shouldn't wire /dev/urandom up into an online cryptosystem (don't use it to produce DH parameters, for instance), but even then, urandom isn't going to be how your system really gets broken.
In your case, experimenting with encrypting whole files with RSA instead of using RSA to exchange keys is what's really going to break your system. This is almost a decent example of how people obsess over the wrong things in cryptosystem design, and why perhaps generalist programmers should stay far, far away from this stuff.
"and why perhaps generalist programmers should stay far, far away from this stuff."
Could I adjust that to say "generalist programmers should stay at least enough in touch with this stuff to know how badly they'll screw it up on their own"?
I've had _many_ heated discussions with inexperienced devs who don't understand just how much you need to know (and how much you need to know that you don't know) before you can start ignoring the simple advice "SSL for data on the move, GPG for data at rest".
Virtual machines receive very little entropy from their environment, which is a real problem when entropy is required for the generation of cryptographic keys.
There have been many attacks based upon vulnerabilities which exist due to misunderstandings entropy, and the need for a secure random number generator, for example the mozilla ssl vulnerability and the debian ssh key vulnerability.
I would agree with you that /dev/urandom can be used for one shot passwords, however I would disagree with you that getting in to the habit of using a non secure random number generator as a source of secure entropy is a bad idea and should be discouraged.
I'd also like to point out that "the standard openssl RSA encryption function" last time I checked worked to spec, and does in fact encrypt a symetric key used for AES (By default), using RSA, including proper cryptographic padding of the key using PKCS#1.
I'm not exactly sure why you thought otherwise.
I do agree with your final assertion, though. Unless you know what you're doing, it's very easy to make a mistake.
