Which SSL/TLS ciphers can be considered secure?
The cipher suites with a "NULL" do not offer data encryption, only integrity check. This means "not secure" for most usages.
The cipher suites with "EXPORT" are, by design, weak. They are encrypted, but only with keys small enough to be cracked with even amateur hardware (say, a basic home PC -- symmetric encryption relying on 40-bit keys). These suites were defined to comply with the US export rules on cryptographic systems, rules which were quite strict before 2000. Nowadays, these restrictions have been lifted and there is little point in supporting the "EXPORT" cipher suites.
The cipher suites with "DES" (not "3DES") rely for symmetric encryption on DES, an old block cipher which uses a 56-bit key (technically, it uses a 64-bit key, but it ignores 8 of those bits, so the effective key size is 56 bits). A 56-bit key is crackable, albeit not in five minutes with a PC. Deep crack was a special-purpose machine built in 1998 for about 250,000 $, and could crack a 56-bit DES key within 4.5 days on average. Technology has progressed, and this can be reproduced with a few dozens FPGA. Still not off-the-shelf-at-Walmart hardware, but affordable by many individuals.
All other cipher suites supported by OpenSSL are non-weak; if you have a problem with them, it will not be due to a cryptographic weakness in the algorithms themselves. You may want to avoid cipher suites which feature "MD5", not because of an actual known weakness, but for public relations. MD5, as a hash function, is "broken" because we can efficiently find many collisions for that function. This is not a problem for MD5 as it is used in SSL; yet, that's enough for MD5 to have a bad reputation, and you are better avoiding it.
Note that the cipher suite does not enforce anything on the size of the server key (the public key in the server certificate), which must be large enough to provide adequate robustness (for RSA or DSS, go for 1024 bits at least, 1536 bits being better -- but do not push it too much, because computational overhead raises sharply with key size).
NIST, a US federal organization which is as accepted and well-known as any security organization can possibly be, has published some recommendations (see especially the tables on pages 22 and 23); this is from 2005 but still valid today. Note that NIST operates on an "approved / not approved" basis: they do not claim in any way that algorithms which are "not approved" are weak in any way; only that they, as an organization, do not vouch for them.
Have you read SSL and TLS: Designing and Building Secure Systems, by Eric Rescorla? It is the accepted classic on SSL, written by one of the leading contributors to the IETF standards working group on SSL. I would expect that it might contain suitable statements about the strength of various SSL ciphersuites.
If that doesn't meet your needs, you might wander down to your friendly library and check out all of the cryptography and security textbooks they have and read the sections written on SSL/TLS.
Basically, if you are looking for a reference to document facts that every security expert already knows, then you might need to do some legwork on your own to find the best citation.
Some small additions to Thomas Pornin's answer: while NIST SP800-52 remains official (if somewhat out of date) for TLS generally, for key sizes specifically it is superseded by SP800-57: part1 covers key sizes and lifetimes in general, revised just last year 2012; part3 covers some specific applications including TLS issued 2010. In brief, they tried to require RSA DSA and DH 2048 bits and ECC 224 bits in 2011 but there was too much pushback so now it's 2014 -- coming soon! (DSA at 2048 or 3072 bits is specified by FIPS 186-3 in 2009, but I don't see much implementation yet. Even openssl did it rather clumsily.) www.CABforum.org concurs with RSA 2048 in 2014; while you don't have to get your cert from an "official" CA, doing visibly less than common "standard" practice tends to get you treated with skepticism. FWIW NIST currently says that strength (Z_n 2048, ECC 224, symmetric 112) is "acceptable" until 2030, after which 3072/256/128 is required; even if they turn out to be wrong, if you go with them you have about as good an excuse as you can find, and you definitely will have lots of good company. Lastly, csrc.nist.gov is a better starting URL for cybsersecurity (NIST as a whole does quite a few other things).