Slashdot Mirror

First, if this were the Debian bug, I feel like they would have said so. I assume there is some other issue. I could be wrong though.

My understanding of the Debian bug was that the OpenSSL key generation code had a bug where /dev/random (or /dev/urandom, whichever it actually used) was being read incorrectly but in a way that happened to work. The line that read the random seed appeared to be dead code despite happening to accidentally read in the random seed, so the Debian maintainer for the package deleted the line. The randomizer was also seeded with the PID of the process, so there was still some randomness (i.e. the bug was not made obvious by the exact same key getting generated every time), but little enough that brute forcing all of the keys became trivial.

See this blog article for a description of the events. Another blog post linked to this bug report in which the OpenSSL team claims the bug is in Valgrind/Purify, not in OpenSSL. I have not recently tried to read the code in detail, so I do not remember if there is actually a right way to fix the Valgrind/Purify warnings.

Small correction -- OpenSSL is a separate, unrelated project.

Surely you jest? Getting amanda to encrypt your backups. Is just a matter of reading some howto files on amanda's website. And, just peeking over at bacula's website, I can see that they have a similar sort of setup. I don't use bacula, but I'm sure it is a matter of following the directions just like with amanda. It is not clear how anyone can consider encrypting backup tapes as a difficult process. For that matter, with TrueCrypt, OpenSSL, GnuPG, FreeBSD's geli, and linux's dm-crypt encryption in general has become easy and accessible. Add to that the hardware acceleration built into most new systems or just pure computational power of modern processors and organizations are remiss for not using encryption at nearly every turn. If you don't, you should lose your job.

Port 110 to check for a broken email header, Port 25 to check for SMTP auth errors

If you're testing user accounts, or logging into your POP3 box to check those mail headers, you may want to consider not using the telnet client anymore. You're potentially compromising any accounts you log into the same as you would with telnet accounts. Your server should be configured to use TLS/SSL for clients, and you can debug them telnet-style with the s_client (in the OpenSSL suite).

Free software is not FIPS certified, and is not going to get certified as free software because no one will pay for certification.

Actually, Free Software has been in the past, and could be again, if a few more vendors who would make money from FIPS-certified Free software would sign on as additional co-sponsor (one or two vendors more may be enough).

It may drive everyone up the wall to use Serina, instead of subversion, for content management - but one is certified & the other is not.

But, subversion doesn't implement encryption directly itself, if it were using OpenSSL with the FIPS module above, AFAIK, it could be shown to be FIPS compliant.

Ditto Putty. I'd love to use it,

Putty is crap, it's only real benefit is providing a terminal emulator because Microsoft can't be bothered to supply one with their OS which is convenient to use (why else would putty ship with telnet support ...). If there was a decent terminal emulator, just Mingw binaries for OpenSSH would probably be much more pupular ... and those would have a chance at FIPS compliance (there are some patches around for OpenSSH FIPS compliance).

There are levels within FIPS 140-2. Software can reach a certain level, beyond that it has to be hardware, IIRC.

FIPS 140-2 is concerned with the security of algorithms used on data leaving and entering a secure system, so a software component simply makes the PC into the device that the FIPS validation applies to. Or that was my reading anyway.

IIRC there is a specific version of openssl that got FIPS 140-2 validation/certification a little while back.

Oh, here it is, looks like a sub-project within openssl, or a subset or some-such.

I echo my sibling's comment in that I have no problem at all with the website's style - I'd far rather have a simplistic straightforward HTML-driven site than some stupid Javascript-redirect-driven graphic-design student project. This is really important for security-related software distribution sites where it's necessary to be absolutely sure where your downloads are coming from.

The site does however have some problems with organisation of content - e.g. it'd be nice if they followed some more de-facto site-structure conventions like having a "Downloads" link to a page which provides the source tarballs, and states explicitly that there are no binaries available ... and maybe even provides links to the more common Linux distro repositories where binaries may be found, even places where (gasp) Windows binaries can be found .... like http://www.stunnel.org/download/binaries.html (the place I always used to go to get my Windows OpenSSL binaries, but which seems a little unmaintained these days) .... or http://www.slproweb.com/products/Win32OpenSSL.html (which is a lot more up to date, and professionally organised).

There is an openssl.org page with info about Win32 binaries :
http://www.openssl.org/related/binaries.html
(which links to the www.slproweb.com site) but it's not easy to find (IMHO).

And then there's the awful documentation, as many others have mentioned. I'd offer to help out with that if I was half-way crypto-competent enough to do so.

But the site's retro style is fine ... the use of colours is restful on the eyes, and avoids use of the stupid 2-point flyspec fonts so beloved of those whose eyes are much younger than mine and who aren't worrying about damaging them :)

http://marc.info/?l=openssl-announce&m=126987886907671&w=2

http://www.openssl.org/source/exp/CHANGES

-molo

You are correct. From openssl.org:

OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson.

Sorry for the misinformation.

The OpenSSL web site lists "[STILL INCOMPLETE]" for each of its manuals.

can people please verify this as accurate?

--- URGENT WARNING ABOUT USING PROXY SERVERS IN IRAN ---
from http//:spectregroup.org, a collaborative research aggregate
(we believe this information to be correct, but do please check for yourself)

excerpted from: http://bit.ly/xJ9aj
http://spectregroup.wordpress.com/2009/06/19/what-tipped-you-off/

EVERY IRANIAN PLEASE USE SSL ENCRYPTION STARTING TOMORROW OR
THE USE OF ANONYMOUS PROXY SERVERS BY IRANIANS IS EXTREMELY UNSAFE

People in Iran please tell every person you know: EVERYONE use SSL proxy servers starting tomorrow on all internet traffic, or please stop using proxies! In spite of everyone's best intentions, when used in limited numbers as they are now, it's likely that internet proxies are simply automating an opposition arrest list (or death list) for the regime.

Please understand that Iran's network-control is state of the art, and Iranian security can inspect ALL traffic easily in an automated fashion, through its centralized choke point. It's likely that anyone using a proxy is quickly spotted and tracked. Proxies are an effective way to get information out, but the use of proxies will not be safe unless EVERY SINGLE PERSON in Iran uses one. EVERYONE.

SSL/TLS (https) can be about 4 to 5 times the packet size in transmission, which makes the bandwidth throttling of the Iranian Security forces more difficult (the Iranian internet is painfully, selectively, slow since it was shut down). If everyone were to use it, for all communications, then all traffic would look the same, and dissidents could not be so easily singled out. This is sometimes called 'faking the weather.' We must recommend either EVERYONE uses SSL proxies, in order to protect each other, or NO ONE does.

IT/Networking professionals will recognize the tactics in commonplace IPS or IDS systems. Iran is clearly using payload inspection and filtering systems- both for blocking, and collecting information. This is done easily, since (without SSL) none of the material being sent is encrypted. (TOR encryption, btw, can be blocked.) Security professionals will understand that scaling firewalls to a national size is a solved problem. Cisco's Netflow is used in network gear throughout the world to record network traffic, and common new style 'deep packet inspection' network products are capable of extremely efficient real-time network processing and data collection.

The longer you wait the more proxy users will be arrested. Tell your grandmothers, tell everyone you know: find a safe SSL proxy, learn to use it, and only use SSL/TLS proxies from now on. They are not difficult to use. If everyone does this, Iran will have an unfiltered internet; to block it the Iranian government would be forced to turn off their WHOLE internet connection (again). Also remember, anonymous proxies can be hijacked: SSL provides validation that you're talking to the right person.

In Summation: Without maximum use in Iran of these SSL/TLS proxy technologies, in spite of best intentions, and with incredible efficiency, the outside internet community is most likely helping to automate an Iranian dissident death/arrest list. I can not overstate this.

Everyone in Iran please start using ssl proxies immediately. today. now.

SSL/TLS
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://www.openssl.org/

PLEASE SPREAD THE WORD:
EVERY IRANIAN USE SSL CRYPTO STARTING TOMORROW!
OR IRANIANS USING PROXIES ARE NOT SAFE

Say it again once more, simply?
On the outside, https proxies (SSL/TLS) for encryption and server validation* are absolutely necessary. Please set them up. (* validation to defend against Iran Security Forces performing man-in-the-middle attacks)

On the inside, EVE

From here: http://www.openssl.org/source/

openssl-0.9.8e.tar.gz
openssl-0.9.8f.tar.gz
openssl-0.9.8g.tar.gz
openssl-0.9.8h.tar.gz
openssl-0.9.8i.tar.gz
openssl-0.9.8j.tar.gz

Would you like to reconsider your statement on versioning?

Why do you care so much ? From the Apache manual: "At this time no web browsers support RFC 2817."

That is the RFC for StartTLS which is something different. I'm talking about SNI which is already supported in Firefox 2, Opera 8, and IE 7. It is also in Apache 2.2.8 and OpenSSL 0.9.8f.

This is SNI ( http://en.wikipedia.org/wiki/Server_Name_Indication ) and it is not supported on Safari (any version I am aware of I just tried a nightly build on an intel iMac) nor on any version of IE on XP or earlier. You can verify by visiting https://sni.velox.ch/ and see if you get a warning.

Also you don't need gnutls for SNI since support for SNI has been backported into OpenSSL 0.9.8: http://cvs.openssl.org/chngview?cn=16435

It's very easy to create a system where it's possible for anybody to verify that the sender is in possession of a given key but not to gain that key themselves.

SSL does in fact stop a DNS-redirect based impostor, if you assume that the keys that the clients trusts are indeed trustworthy. The problem in all of the above systems is three-fold: a.) making sure the cipher is secure (AFAIK, nobody has an efficient way to break RSA yet), b.) making sure the implementation is sound (hence Debian OpenSSL snafu earlier this year), and c.) knowing which keys to trust.

In a system where all keys are registered by a central, trusted registrar (like easypass), (c) is dealt with. Sadly, a lot of RFID authentication schemes fail tests (a) and (b). Attacks on OpenSSL (Debian debacle aside) often concentrate on (c), because your browser has to trust some other authority to sign off on the validity of a key, and often those authorities are not very rigorous and can be tricked.

Caveat - only 1 HTTPS per IP.

That's not necessarily true: Subject Alternative Name

There's plenty of ways that turns out less than ideal, but 90% of the time if you're sharing an IP, it's not a big deal to share a cert.

According to http://www.openssl.org/support/, openssl-dev is for the developers of openssl itself. To quote the list description: Discussions on development of the OpenSSL library. Not for application development questions!

also the README in the source code in quesiton says, "Development is coordinated on the openssl-dev mailing list (see http://www.openssl.org/ for information on subscribing)."

No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL

Incorrect, no matter what Ben claims. According to http://www.openssl.org/support/, openssl-dev is for the developers of openssl itself. To quote the list description: Discussions on development of the OpenSSL library. Not for application development questions!

So yes, perhaps Kurt could have been more explicit in his description of what he was trying to do, but he was definitely using the appropriate address to reach the developers.

noah

Has someone actually checked the random output for cryptographic soundness?

The proper source of cryptographic-quality random bits in Linux is "/dev/random". Reading uninitialized memory is not a good source of entropy - it might be initialized to some constant value, especially if you're compiling with a debug allocator or running under a virtual machine monitor.

OpenSSL makes substantial efforts to get a good random starter. Unless someone did something so stupid that OpenSSL didn't use /dev/random, it should still work. OpenSSL is supposed to have a check for bad random seeds. Was that bypassed, or doesn't it work, or what?

Obtaining a good source of randomness is hard. Computers are rather deterministic. Historically, there have been major failures in this area. See "Venona" where the USSR was generating "one-time pads" by having people type random digits on typewriters. Arlington Hall, NSA's predecessor, cracked that. Humans aren't random enough. True random number generation requires special hardware, like a noise diode or a radiation source.

"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin." -- John von Neumann

I have the following config in my sendmail.mc:

FEATURE(`require_rdns')dnl
FEATURE(`block_bad_helo')dnl
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"Message from $&{client_addr} rejected - see http://www.spamhaus.org/query/bl?ip="$&{client_addr}', `t')dnl
FEATURE(`enhdnsbl', `bl.spamcop.net', `"Message from $&{client_addr} rejected - see http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl
FEATURE(`dnsbl',`combined.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/lookup?$&{client_addr}')dnl
FEATURE(`dnsbl',`list.dsbl.org',`Message from $&{client_addr} rejected - see http://www.dsbl.orgdnl/
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"Message from $&{client_addr} rejected - see http://www.sorbs.net/"')dnl
FEATURE(`dnsbl',`dnsbl-1.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl
FEATURE(`dnsbl',`dnsbl-2.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl
FEATURE(`dnsbl',`dnsbl-3.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl

There isn't even any problem doing a secure setup for persons roaming, in which case it's possible to set up a SMTP AUTH on a different port. I have at the same time elected to use SMTPS (SMTP over SSL), which means that any password and information sent over the net is encrypted.

Below is the code I use for listening on a secondary port (465/smtps) with AUTH and certificate handling for encryption.

DAEMON_OPTIONS(`Port=25')dnl
DAEMON_OPTIONS(`Port=465, Modifiers=as')dnl
define(`confPRIVACY_FLAGS', `noexpn novrfy authwarnings')dnl
define(`confFALLBACK_MX', `smtp.bredband.net')dnl
define(`confCACERT_PATH', `...ssl')dnl
define(`confCACERT', `...ssl/cacert.pem')dnl
define(`confSERVER_CERT', `...ssl/certs/smtp.pem')dnl
define(`confSERVER_KEY', `...ssl/certs/smtp.pem')dnl
define(`confAUTH_OPTIONS', `p,y')dnl
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 PLAIN LOGIN')dnl

At least the actions I have taken discourages the spammers good enough and makes me feel reasonable safe. (there is always another leak, but you have to find it first).

Seriously. There are already libraries such as FLTK and QT for the graphic front end. For the back end, you could use XySSL, OpenSSL, or even GNU GPG.

I'm about 20 hours into an encryption client, and I've already got people using it. I initially wanted to use GPG, but realized that most technophobes won't go for a command line application. So I pulled out FLUID (the FLTK design utility) and had a prototype working within hours.

Today, there's no excuse for not encrypting your email. I realize that you may think you have Constitutional rights in this regard, but GW & Co. have the guns, the taxpayer financing, and even the (unsolicited!) cooperation of the major network carriers. It doesn't matter what you think the Constitution says if you can't even get a trial. You're on your own from here on out.

So why encrypt, even if you've nothing to hide? Well, simple, really. Why let the government violate the 4th ammendment with impunity? If you encrypt your email, the government can't perform secret, mass surveillance. Sure, they can pound on your door, and even demand the key. You might even have to give it to them. But in them doing so, you've achieved three key goals:

1. In order to get the key from you, they'll have to contact you. So they can't secretly eavesdrop on your communications.
2. Should you refuse the key, they will have to convince a judge to order you to divulge it - thus, your 4th ammendment rights are preserved - the judge will require probable cause before issuing the order.
3. In demanding the key, the issue will move from the administrative branch to the judicial branch. You want to force the government into the courtroom so that your other rights are not trampled as well.

Encryption is highly Constitutional (TM) software. It keeps terrorists from eavesdropping on our conversations, knowing our whereabouts, and stealing our valuable intellectual property. If the government can't read my email, neither can the terrorists.

Be patriotic. Support the Constitution. Encrypt everything.

At least as far I can tell from a quick check, and that match my somewhat vague memory.

Eivind.

That wouldn't be anything new, look at OpenSSL (or more specifically ssleay):

The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]

the main source of theo thinking SVN isn't secure, is because that control freak didn't write it himself. which is ironic because openssl and openssh are 2 packages responsible for huge security holes over the years, both of which are his babies.

The OpenCVS project was started after discussions regarding the latest GNU CVS vulnerabilities that came out. Although CVS is widely used, its development has been mostly stagnant in the last years and many security issues have popped up, both in the implementation and in the mechanisms.

Perhaps for your purposes. However, the CVS license it not consistent with the goals and philosophies of OpenBSD. So they created OpenCVS with a license that is appropriate.

the main source of theo thinking SVN isn't secure, is because that control freak didn't write it himself.

Do you have a link pointing to his quote on that?

openssl and openssh are 2 packages responsible for huge security holes over the years, both of which are his babies.

OpenSSL is not Theo's "baby".

OpenSSH's security, while not perfect, has been excellent. Your unsubstantiated attribution of "huge security holes" to it seems to be intended as little more than a troll, since you did not provide any citations.

The only new thing here is the standard format for the compliance with the court order (and the new requirement that you be able to produce the records for the court). Most ISPs have been saying, "yeah, we don't have that information because we wouldn't have the capacity to store it, duh" up until now.

Did you feel like your civil liberties were stripped away when the court authorized a wiretip on so-and-so or whats-his-face? How do you suppose the court or the legislature would react if your telco said, "Yeah, we don't have the equipment to tap that line." I don't think that would go over so well. Thus: CALEA.

What frightens me a great deal more than the ability of the court to order us to produce data (and the requirement that we store it) is the remote control wire tapping device installed at the police station that can listen in on any line at our small phone company.

They're supposed to get a warrant first, but my feelings indicate that if I were a cop (and believed I was helping people) I probably wouldn't bother with a warrant until I knew there was something to get a warrant about. That is much more serious than this. Let me introduce you to my little friends openssl, openssh, openvpn and gnupg.

If you believe the discrete log problem is "hard" then you have no worries. Now try doing that with your phone...

There are multiple ways to avoid this vulnerability. Any one of the following measures is sufficient. 1. Upgrade the OpenSSL server software. The vulnerability is resolved in the following versions of OpenSSL: - in the 0.9.7 branch, version 0.9.7k (or later); - in the 0.9.8 branch, version 0.9.8c (or later). OpenSSL 0.9.8c and OpenSSL 0.9.7k are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8c.tar.gz MD5 checksum: 78454bec556bcb4c45129428a766c886 SHA1 checksum: d0798e5c7c4509d96224136198fa44f7f90e001d o openssl-0.9.7k.tar.gz MD5 checksum: be6bba1d67b26eabb48cf1774925416f SHA1 checksum: 90056b8f5e518edc9f74f66784fbdcfd9b784dd2 The checksums were calculated using the following commands: openssl md5 openssl-0.9*.tar.gz openssl sha1 openssl-0.9*.tar.gz 2. If this version upgrade is not an option at the present time, alternatively the following patch may be applied to the OpenSSL source code to resolve the problem. The patch is compatible with the 0.9.6, 0.9.7, 0.9.8, and 0.9.9 branches of OpenSSL. o http://www.openssl.org/news/patch-CVE-2006-4339.tx t Whether you choose to upgrade to a new version or to apply the patch, make sure to recompile any applications statically linked to OpenSSL libraries.

There are multiple ways to avoid this vulnerability. Any one of the following measures is sufficient. 1. Upgrade the OpenSSL server software. The vulnerability is resolved in the following versions of OpenSSL: - in the 0.9.7 branch, version 0.9.7k (or later); - in the 0.9.8 branch, version 0.9.8c (or later). OpenSSL 0.9.8c and OpenSSL 0.9.7k are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8c.tar.gz MD5 checksum: 78454bec556bcb4c45129428a766c886 SHA1 checksum: d0798e5c7c4509d96224136198fa44f7f90e001d o openssl-0.9.7k.tar.gz MD5 checksum: be6bba1d67b26eabb48cf1774925416f SHA1 checksum: 90056b8f5e518edc9f74f66784fbdcfd9b784dd2 The checksums were calculated using the following commands: openssl md5 openssl-0.9*.tar.gz openssl sha1 openssl-0.9*.tar.gz 2. If this version upgrade is not an option at the present time, alternatively the following patch may be applied to the OpenSSL source code to resolve the problem. The patch is compatible with the 0.9.6, 0.9.7, 0.9.8, and 0.9.9 branches of OpenSSL. o http://www.openssl.org/news/patch-CVE-2006-4339.tx t Whether you choose to upgrade to a new version or to apply the patch, make sure to recompile any applications statically linked to OpenSSL libraries.

There are multiple ways to avoid this vulnerability. Any one of the following measures is sufficient. 1. Upgrade the OpenSSL server software. The vulnerability is resolved in the following versions of OpenSSL: - in the 0.9.7 branch, version 0.9.7k (or later); - in the 0.9.8 branch, version 0.9.8c (or later). OpenSSL 0.9.8c and OpenSSL 0.9.7k are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8c.tar.gz MD5 checksum: 78454bec556bcb4c45129428a766c886 SHA1 checksum: d0798e5c7c4509d96224136198fa44f7f90e001d o openssl-0.9.7k.tar.gz MD5 checksum: be6bba1d67b26eabb48cf1774925416f SHA1 checksum: 90056b8f5e518edc9f74f66784fbdcfd9b784dd2 The checksums were calculated using the following commands: openssl md5 openssl-0.9*.tar.gz openssl sha1 openssl-0.9*.tar.gz 2. If this version upgrade is not an option at the present time, alternatively the following patch may be applied to the OpenSSL source code to resolve the problem. The patch is compatible with the 0.9.6, 0.9.7, 0.9.8, and 0.9.9 branches of OpenSSL. o http://www.openssl.org/news/patch-CVE-2006-4339.tx t Whether you choose to upgrade to a new version or to apply the patch, make sure to recompile any applications statically linked to OpenSSL libraries.

There are multiple ways to avoid this vulnerability. Any one of the following measures is sufficient. 1. Upgrade the OpenSSL server software. The vulnerability is resolved in the following versions of OpenSSL: - in the 0.9.7 branch, version 0.9.7k (or later); - in the 0.9.8 branch, version 0.9.8c (or later). OpenSSL 0.9.8c and OpenSSL 0.9.7k are available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file names are: o openssl-0.9.8c.tar.gz MD5 checksum: 78454bec556bcb4c45129428a766c886 SHA1 checksum: d0798e5c7c4509d96224136198fa44f7f90e001d o openssl-0.9.7k.tar.gz MD5 checksum: be6bba1d67b26eabb48cf1774925416f SHA1 checksum: 90056b8f5e518edc9f74f66784fbdcfd9b784dd2 The checksums were calculated using the following commands: openssl md5 openssl-0.9*.tar.gz openssl sha1 openssl-0.9*.tar.gz 2. If this version upgrade is not an option at the present time, alternatively the following patch may be applied to the OpenSSL source code to resolve the problem. The patch is compatible with the 0.9.6, 0.9.7, 0.9.8, and 0.9.9 branches of OpenSSL. o http://www.openssl.org/news/patch-CVE-2006-4339.tx t Whether you choose to upgrade to a new version or to apply the patch, make sure to recompile any applications statically linked to OpenSSL libraries.

==============

openssl (0.9.8a-7ubuntu0.1) dapper-security; urgency=low

* SECURITY UPDATE: signature forgery in some cases.

* Apply http://www.openssl.org/news/patch-CVE-2006-4339.tx t:

- Check excessive data in padding of PKCS #1 v1.5 signatures to prevent applications from incorrectly verifying the certificate.

* References:

CVE-2006-4339

http://www.openssl.org/news/secadv_20060905.txt

==============

openssl (0.9.8a-7ubuntu0.1) dapper-security; urgency=low

* SECURITY UPDATE: signature forgery in some cases.

* Apply http://www.openssl.org/news/patch-CVE-2006-4339.tx t:

- Check excessive data in padding of PKCS #1 v1.5 signatures to prevent applications from incorrectly verifying the certificate.

* References:

CVE-2006-4339

http://www.openssl.org/news/secadv_20060905.txt

I would hope that all serious users of OpenSSL have already patched this. FreeBSD and Debian were on top of it the same day it was announced.

I don't know about Debian, but FreeBSD didn't issue an advisory until the day after this went public. We have a very strict policy about making sure that security updates won't break anything, and OpenSSL's original patch was broken and not fixed until a day later.

In general you're right, though -- we hear about security issues before they go public and make sure we have advisories and patches ready.

This weakness was first described at the CRYPTO conference in August, and a technical explanation of the exploit was public on Aug. 27, Open SSL issued its advisory and patch on Sept. 5 and the Netcraft article cited by ZDNet has been online since Sept. 7. So while this is a potentially problematic security issue, it's not brand new, has been patched by OpenSSL and quite a few vendors have issued patches as well.

Slashdot. News for time travellers from just arriving here from two and half weeks ago.
http://www.openssl.org/news/secadv_20060905.txt

I would hope that all serious users of OpenSSL have already patched this. FreeBSD and Debian were on top of it the same day it was announced. Others too, no doubt.

I'm guessing some of the product's will get cut off. Going out on a limb here, but I'm guessing Most of the Keon family will get cut off, at least the toolkits with openssl and boncycastle as options for customers.
The big question is if the CA too will be cut-off... there is lots of viable options here too Ejbca for example <shameless plug>There is commercial support available</shameless plug>.

It's called SSL.
Or did you actually intend to ask a more useful question?

"This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed."

See the OpenSSL FAQ).

# openssl(1): [STILL INCOMPLETE]
Manual page documenting the openssl command line tool.

# ssl(3): [STILL INCOMPLETE]
Manual page documenting the OpenSSL SSL/TLS library.

# crypto(3): [STILL INCOMPLETE]
Manual page documenting the OpenSSL Crypto library.

# HOWTO: [STILL INCOMPLETE]
HOWTO documents to introduce concepts or explain them in a way that is not possible in the manuals.

There's just one problem. This perception of the software-as-services model is a jaundiced misrepresentation of the way that on-demand applications actually work. No on-demand customer pays simply for the privilege of accessing the software. They pay because the software delivers business results. And that simple distinction exposes once and for all the clay feet, the emperor's new clothes, of the traditional applications software industry. Their products don't actually work until they've been tweaked and customized by customers or partners, and therefore the licence of itself has no out-of-the-box value to the end user. Asking people to pay for the privilege of using the software isn't offering a service, it's taking a liberty. It's as much of a nonsense as asking a punter to pay a performance fee for whistling a copyrighted tune. If I'm paying a fee to watch a movie, listen to a song, or use an application, I expect to experience a professional, finished execution.

True on-demand application vendors understand this. Conventional software vendors seem to think the world still owes them a living, just for bothering to write some software.


This article sounds as if the guy was jaded from the start. His complaints are similar to those people who first scoffed at the notion of leasing a car instead of buying it. Some may consider it foolish, but some also see the benefits. In my experience you can lease a car for 12 months, have the "owner" of the car (or software) continually maintain it when it needs it.

Don't read too deeply in on that analogy, please.

But BOTHERING to write some software? By us Bothering to write some software you have some of the best software out there that's been used to secure most of the IT infrastructure the world runs on. Apache, The Linux Kernel, The Various BSD's, SQL Databases, Iptables, SNORT IDS software, OpenSSL, and many many more!

This guy is just trolling. The article is slanted because he believes that once written, any bugs, flaws (as in it doesn't do this the _way_ it should for ME) should all be done for free simply because he or general consumers are greedy. To a point, bug fixes should be fixed like glaring security flaws that could be used to take over your computer (ala windows in general, yes I'm biased) or damage your information etc.

But get real. If you paid ONCE for your anti-virus software and expected it to work flawlessly and capture all viruses, worms etc without having to pay extra every year to maintain that reliability you're just out of your mind. There is no incentive to keep something up for free especially in an evolving industry. One that evolves and almost 2-5 times the normal rate of other industries.

Think of it this way. You pay a subscription service similar to that of an anti-virus vendor. Receive continual updates, bug fixes, serious flaws get fixed for an annual price. This ensures the developers can work and continue to live as well. Why not? If you don't pay for the next years license, you simply don't get major version upgrades (maybe a serious bug fix or service pack) or new "features".

I'm not keen on the idea of keeping your apps on a server/central location, unless it's on my home network and I have the option to install it centrally or on each workstation. It's just foolish to do it that way. But this guy's "it's mine, I want it all forever" after a simple purchase doesn't cut it. Want that new fender or tires? They're better quality than the current tires you have, then pay for them. Don't expect it for free buddy.

This guy really pissed me off. And I have a football game to watch.

Like in all software, there is security issues, but it's not quite as bleak as the list you presented (one reflect FreeBSD on Alpha, another about a script on Debian, if I remember correctly, some changes from default config (like disabling Priv Sep)).

Have a look at OpenSSH Security for the various security issues. The opensSL project has a similar page.

Put an Open in front of your SSL problem
Voila

Get OpenSSL and roll your own, any time, any platform... always been that way... and this is news? Some script-kiddy-turned-public-relations-director figured this out? Good for j00. As for everyone else, nothing to see here that we don't already know.

There is nothing said about the severity of the vulnerabilities.

There have been quite a few _significant_ problems with OpenSSL in the past year that I imagine contributed to the evaluation. That said, I'm still happily running Apache.

If your system has an md5sum command, it will also have a sha1sum command. Same idea, different output: feed each of them a file and they will give you a hash of that file that fits in 128-bits (md5) or 160-bits (sha1).

If you have "openssl" installed, you could also use openssl to generate the hashes. (supported hashes)

For md5 hashes:
$ openssl md5 filenames...
Output: MD5(filename)= hash

For sha1 hashes:
$ openssl sha1 filenames...
Output: SHA1(filename)= hash

If your system has an md5sum command, it will also have a sha1sum command. Same idea, different output: feed each of them a file and they will give you a hash of that file that fits in 128-bits (md5) or 160-bits (sha1).

If you have "openssl" installed, you could also use openssl to generate the hashes. (supported hashes)

For md5 hashes:
$ openssl md5 filenames...
Output: MD5(filename)= hash

For sha1 hashes:
$ openssl sha1 filenames...
Output: SHA1(filename)= hash

Probably a lot easier to just use SSL. Most existing protocols (like HTTP, POP3, IMAP) add an encryption layer this way.

There are already some P2P programs that support encryption, such as Freenet and MUTE.

Yeah, but you don't have physical control over the pipes between yor server and all your clients. How do you think your bits get sent back and forth? I just have to put an intercept between you and your clients to grab all the data I want.

OpenSSL. Many IRCds and clients these days support encryption.

This would be some sort of program that can sit on an ISP's trunks, and grab all traffic that looked like IRC traffic and dump it in a log. Since it is the CIA, (And they are in theory, the Intelligence 'Offense') it might be a small embedded hardware solution that has a built in microdrive. It would be very handy to have a CIA controled operative slip in to a NOC in a hostile country, snap it onto a trunk in an unobtrusice location and pick it up a month later.

They already have this, it's called Carnivore. It's not a secret from the ISPs, either, they know it's there. But they are prohibited by law from telling the public whether or not a Carnivore box is monitoring their traffic. Additionally, Carnivore is not only for email these days.

(You can walk my grandma through downloading a gzipped tarball.)

Grandma ACclick here.