Slashdot Mirror

After nearly 20 years and 31,000 commits, OpenSSL wants to change to Apache License v2.0. They're now tracking down all 400 contributors to sign new license agreements, a process expected to take several months. Slashdot reader rich_salz shares links to OpenSSL's official announcement (and their agreement-collecting web site). "This re-licensing activity will make OpenSSL, already the world's most widely-used FOSS encryption software, more convenient to incorporate in the widest possible range of free and open source software," said Mishi Choudhary, Legal Director of Software Freedom Law Center and counsel to OpenSSL. "OpenSSL's team has carefully prepared for this re-licensing, and their process will be an outstanding example of 'how to do it right.'"
Click through for some comments on the significance of this move from the Linux Foundation, Intel, and Oracle.

• "The Linux Foundation is excited to see the OpenSSL project re-licensing under the Apache License. Using a standard and well-understood license is a huge benefit when incorporating a FOSS project into other projects and products... this license move will further help to ensure it remains one of the most important and relied-upon open source projects in the world."
  
  -- Nicko van Someren, Chief Technology Officer, the Linux Foundation

• "Oracle is proud to extend its collaboration with the OpenSSL Foundation by relicensing its contributions of elliptic curve cryptography. OpenSSL is a critical component in both Oracle products and the infrastructure of the Internet, and we strongly believe the increased use of cryptography fostered by OpenSSL will benefit the entire enterprise software community."
  
  -- Jim Wright, Chief Architect of Open Source Policy, Strategy, Compliance and Alliances, Oracle

• "Intel is thrilled to see OpenSSL moving to the standard Apache 2.0 license, improving license compatibility within the Open Source ecosystem. This will help defragment the open source cryptography ecosystem, leading to stronger and more pervasive use of crypto to improve privacy and security in the global technology infrastructure."
  
  -- Imad Sousou, Vice President and General Manager of the Open Source Technology Center, Intel

After nearly 20 years and 31,000 commits, OpenSSL wants to change to Apache License v2.0. They're now tracking down all 400 contributors to sign new license agreements, a process expected to take several months. Slashdot reader rich_salz shares links to OpenSSL's official announcement (and their agreement-collecting web site). "This re-licensing activity will make OpenSSL, already the world's most widely-used FOSS encryption software, more convenient to incorporate in the widest possible range of free and open source software," said Mishi Choudhary, Legal Director of Software Freedom Law Center and counsel to OpenSSL. "OpenSSL's team has carefully prepared for this re-licensing, and their process will be an outstanding example of 'how to do it right.'"
Click through for some comments on the significance of this move from the Linux Foundation, Intel, and Oracle.

• "The Linux Foundation is excited to see the OpenSSL project re-licensing under the Apache License. Using a standard and well-understood license is a huge benefit when incorporating a FOSS project into other projects and products... this license move will further help to ensure it remains one of the most important and relied-upon open source projects in the world."
  
  -- Nicko van Someren, Chief Technology Officer, the Linux Foundation

• "Oracle is proud to extend its collaboration with the OpenSSL Foundation by relicensing its contributions of elliptic curve cryptography. OpenSSL is a critical component in both Oracle products and the infrastructure of the Internet, and we strongly believe the increased use of cryptography fostered by OpenSSL will benefit the entire enterprise software community."
  
  -- Jim Wright, Chief Architect of Open Source Policy, Strategy, Compliance and Alliances, Oracle

• "Intel is thrilled to see OpenSSL moving to the standard Apache 2.0 license, improving license compatibility within the Open Source ecosystem. This will help defragment the open source cryptography ecosystem, leading to stronger and more pervasive use of crypto to improve privacy and security in the global technology infrastructure."
  
  -- Imad Sousou, Vice President and General Manager of the Open Source Technology Center, Intel

An anonymous reader writes: The OpenSSL project has released versions 1.0.2g and 1.0.1s to address a high severity security issue known as the DROWN attack (CVE-2016-0800) which allows attackers to break HTTPS and steal encrypted information. In layman terms, the attack uses an improperly patched issue (from 1998) in SSL to attack websites using the more modern TLS protocol. Servers where admins use SSL and TLS are in danger. Additionally, servers where only TLS is used, but the admins are sharing the same certificate for other servers where they have SSL, are also vulnerable, since the attack targets RSA, employed in both SSL and TLS. The entire attack is also easy to carry out, costing only $440 on Amazon EC2.

itwbennett writes: The OpenSSL Software Foundation has released new patches for the popular open-source cryptographic library, but for two of its older branches, OpenSSL 1.0.0t and 0.9.8zh, they will likely be the last security updates because support for these these two branches will end on Dec. 31. Previous research has shown that many companies using in-house built software keep poor records of which library versions their developers used in which of their applications. 'This makes it very likely that some systems and applications with OpenSSL 0.9.8 and 1.0.0 will never be updated, leaving them exposed to any critical vulnerabilities found in the library in the future,' writes Lucian Constantin.

msm1267 writes: The mystery OpenSSL patch released today addresses a critical certificate validation issue where anyone with an untrusted TLS certificate can become a Certificate Authority. While serious, the good news according to the OpenSSL Project is that few downstream organizations have deployed the June update where the bug was introduced. From the linked piece: The vulnerability allows an attacker with an untrusted TLS certificate to be treated as a certificate authority and spoof another website. Attackers can use this scenario to redirect traffic, set up man-in-the-middle attacks, phishing schemes and anything else that compromises supposedly encrypted traffic. [Rich Salz, one of the developers] said there are no reports of public exploits.

An anonymous reader writes: The Register reports that upcoming OpenSSL versions 1.0.2d and 1.0.1p are claimed to fix a single security defect classified as "high" severity. It is not yet known what this mysterious vulnerability is — that would give the game away to attackers hoping to exploit the hole before the patch is released to the public. Some OpenSSL's examples of "high severity" vulnerabilities are a server denial-of-service, a significant leak of server memory, and remote code execution. If you are a system administrator, get ready to patch your systems this week. The defect does not affect the 1.0.0 or 0.9.8 versions of the library.

New submitter eyeareque writes: It's time to patch OpenSSL again. The OpenSSL project has patched several moderate- and low-severity security vulnerabilities and also has added protection against the Logjam attack in new releases of the software. Personally I wish that OpenSSL released these in a predictable cadence. Patch Tuesday maybe?

An anonymous reader writes As announced on Monday, the OpenSSL project team has released new versions of the cryptographic library that fix a number of security issues. The announcement created a panic within the security community, who were dreading the discovery of another Heartbleed-type bug, but as it turns out, the high severity issue fixed is a bug than can be exploited in a DoS attack against servers. Other issues fixed are mostly memory corruption and DoS flaws of moderate and low severity.

kthreadd writes The OpenSSL project has released its second feature release of the OpenSSL 1.0 series, version 1.0.2 which is ABI compatible with the 1.0.0 and 1.0.1 series. Major new features in this release include Suite B support for TLS 1.2 and DTLS 1.2 and support for DTLS 1.2. selection. Other major changes include TLS automatic EC curve selection, an API to set TLS supported signature algorithms and curves, the SSL_CONF configuration API, support for TLS Brainpool, support for ALPN and support for CMS support for RSA-PSS, RSA-OAEP, ECDH and X9.42 DH.

itwbennett writes: Server administrators are advised to upgrade OpenSSL again to fix eight new vulnerabilities, two of which can lead to denial-of-service (DoS) attacks. Although the flaws are only of moderate and low severity, "system administrators should plan to upgrade their running OpenSSL server instances in the coming days," said Tod Beardsley, engineering manager at vulnerability intelligence firm Rapid7.

An anonymous reader writes Google today announced plans to disable fallback to version 3 of the SSL protocol in Chrome 39, and remove SSL 3.0 completely in Chrome 40. The decision follows the company's disclosure of a serious security vulnerability in SSL 3.0 on October 14, the attack for which it dubbed Padding Oracle On Downgraded Legacy Encryption (POODLE). Following Mozilla's decision on the same day to disable SSL 3.0 by default in Firefox 34, which will be released on November 25, Google has laid out its plans for Chrome. This was expected, given that Google Security Team's Bodo Möller stated at the time: "In the coming months, we hope to remove support for SSL 3.0 completely from our client products."

AlbanX sends word that security researchers from Google have published details on a vulnerability in SSL 3.0 that can allow an attacker to calculate the plaintext of encrypted communications. Google's Bodo Moller writes, SSL 3.0 is nearly 15 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue. Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response (PDF) is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

Trailrunner7 (1100399) writes 'There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software. The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That's not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle. Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.'

Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012." Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.

tearmeapart writes "A major security issue has been found in all OpenSSL packages. You probably want to download your preferred OpenSSL package as soon as possible. Changes to the CVS repository are detailed on the OpenSSL timeline."

tearmeapart writes "A major security issue has been found in all OpenSSL packages. You probably want to download your preferred OpenSSL package as soon as possible. Changes to the CVS repository are detailed on the OpenSSL timeline."

tearmeapart writes "A major security issue has been found in all OpenSSL packages. You probably want to download your preferred OpenSSL package as soon as possible. Changes to the CVS repository are detailed on the OpenSSL timeline."

First time accepted submitter joost.bijl writes "Yesterday the Dutch government took a step to further improve the adoption of Open Source in its ranks. It has officialy approved a modified version of the open source VPN software OpenVPN for use on the governmental level 'Departementaal Vertrouwelijk' (Restricted). The release is called OpenVPN-NL and is fully open-source and available for use. The software has undergone a security evaluation by the Dutch government's national communications security agency (NLNCSA). The major change is the removal of OpenSSL as the cryptographic core of OpenVPN-NL. Instead, the Dutch government opted to include the smaller, better readable and documented open source library PolarSSL to provide the cryptographic and SSL/TLS functionality. The Dutch IT Security company Fox-IT worked together with both OpenVPN and PolarSSL communities and modified the stock software to support the government evaluation process. In total 8000 lines of code and 4000 lines of documentation were checked in to the OpenVPN trunk."

hardaker writes "After over 11 years of development since the start of the OpenSSL Project (1998-12-23), OpenSSL version 1.0.0 has finally hit the shelves of the free-for-all store."

hardaker writes "After over 11 years of development since the start of the OpenSSL Project (1998-12-23), OpenSSL version 1.0.0 has finally hit the shelves of the free-for-all store."

gfilion writes "Updated versions of OpenSSL are now available which correct two security issues: A null-pointer assignment during SSL handshake and an out-of-bounds read that affects Kerberos ciphersuites. Full advisory available on OpenSSL site and US-CERT."

SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities, the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."

SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities, the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."

SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities, the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."

Clyde writes "The different worlds of DRM and Open Source have come together under OGG-S, a project that just recently went to beta with their Open Source DRM toolkit. The project license in GPL and uses OpenSSL for its encryption engine. It will be interesting to see if this project helps to spread the acceptance of Ogg Vorbis."

in4mation writes "The folks at LASEC have found a flaw in the SSL protocol. Quoting Professor Serge Vaudenay from a BBC article the security problem is in 'the SSL protocol itself and not in how we use it or how we implement it.' Apparently the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack." Update: 02/20 20:52 GMT by T : Kurt Seifried writes to say that this is almost exactly wrong: "The flaw is in IMPLEMENTATION, NOT THE PROTOCOL. Due to the way error checks are handled an attacker can find out which error condition occurred by measuring the response. The solution is trivial, a path that forces OpenSSL to do the second check even if the first one fails, thus denying the remote attacker any information as to which exact error condition occurred." He includes a link to the security advisory at openssl.org. Update: 02/20 21:49 GMT by T : Read on below for some more information from SSL 3.0 designer Paul Kocher.

Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:

The referenced paper (http://lasecwww.epfl.ch/memo_ssl.shtml) describes how timing variations in SSL/TLS implementations can be used in certain situations to slowly gather information about encrypted data. If the certain conditions are met, the attacker can decrypt some information from the message (e.g., a password). Strictly speaking, the fact that implementations reveal sensitive information in timing channels is an implementation issue, not a flaw in the underlying cryptographic protocol. This doesn't make the issue unimportant, however, and timing attacks are big deal for implementers because they are easy to introduce, notoriously tricky to detect, and often difficult to eliminate.

Answers to general questions:

1. Is it still okay to send my credit card number over SSL? Yes. This attack is not applicable to web shopping and there are much easier ways that fraudsters steal credit card information (e.g., breaking into merchants' web sites -- a problem that SSL can't solve). In any case, the bank is generally responsible if someone steals your card info.

2. Is the paper "real" or another bogus "I broke SSL" claim? The paper is legit. The Slashdot announcement suggests that SSL itself is broken, however, which is a bit misleading.

2. Is this a practical attack to exploit? Cryptographers need to be paranoid about unexpected situations. As a result, attacks can be important even if they are not practical to exploit under real- world conditions. The attack described in this paper is similar; while there are quite a few preconditions for mounting the attack, this does not make the research unimportant or mean that people should ignore the work. Specific requirements to mount the attack include:

• The session has to use CBC mode. The vast majority of SSL connections use RC4, for which the attack is not applicable. Because of the algorithm negotiation used in SSL/TLS is secured in the initial handshake, man-in-the- middle attackers should not be able affect the outcome of the algorithm selection process.

• The attacker has to act as an active man-in-the-middle attacker. Passive eavesdropping is not sufficient.
• The server's SSL implementation has to be vulnerable (see #3 below). The protocol also has to be oblivious to repeated failures.

• The target protocol also has to have some very specific characteristics that allow the adversary to form the right kinds of messages. For most uses of SSL (e.g., normal web browsing), this type of attack does not generally apply.

3. Can affected implementations be fixed? Yes. OpenSSL has been updated (http://www.openssl.org/news/secadv_20030219.txt). For more information, also see http://www.openssl.org/~bodo/tls-cbc.txt. I don't know what other vendors/projects are doing.

4. Is this an issue for the client or the server? Normally, this would only be an issue for the "server" (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections.

A couple of final comments:

I'm constantly amazed by the number of ways that it's possible to screw up security. Overall, SSL 3.0 seems to have aged well, but I wish I'd done a better job of handling errors in the design. In particular, error handling was involved in both of the attacks against SSL that I consider non-obvious, notably Bleichenbacher's attack and CBC-padding attacks such as this one. While these types of attacks weren't known when I was designing SSL 3.0, I generally wish I'd provided less information in error messages.

Finally, I also want to give thanks everyone who has helped to study SSL's security, contributed to implementations, and helped shepherd it through the standards processes."

in4mation writes "The folks at LASEC have found a flaw in the SSL protocol. Quoting Professor Serge Vaudenay from a BBC article the security problem is in 'the SSL protocol itself and not in how we use it or how we implement it.' Apparently the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack." Update: 02/20 20:52 GMT by T : Kurt Seifried writes to say that this is almost exactly wrong: "The flaw is in IMPLEMENTATION, NOT THE PROTOCOL. Due to the way error checks are handled an attacker can find out which error condition occurred by measuring the response. The solution is trivial, a path that forces OpenSSL to do the second check even if the first one fails, thus denying the remote attacker any information as to which exact error condition occurred." He includes a link to the security advisory at openssl.org. Update: 02/20 21:49 GMT by T : Read on below for some more information from SSL 3.0 designer Paul Kocher.

Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:

The referenced paper (http://lasecwww.epfl.ch/memo_ssl.shtml) describes how timing variations in SSL/TLS implementations can be used in certain situations to slowly gather information about encrypted data. If the certain conditions are met, the attacker can decrypt some information from the message (e.g., a password). Strictly speaking, the fact that implementations reveal sensitive information in timing channels is an implementation issue, not a flaw in the underlying cryptographic protocol. This doesn't make the issue unimportant, however, and timing attacks are big deal for implementers because they are easy to introduce, notoriously tricky to detect, and often difficult to eliminate.

Answers to general questions:

1. Is it still okay to send my credit card number over SSL? Yes. This attack is not applicable to web shopping and there are much easier ways that fraudsters steal credit card information (e.g., breaking into merchants' web sites -- a problem that SSL can't solve). In any case, the bank is generally responsible if someone steals your card info.

2. Is the paper "real" or another bogus "I broke SSL" claim? The paper is legit. The Slashdot announcement suggests that SSL itself is broken, however, which is a bit misleading.

2. Is this a practical attack to exploit? Cryptographers need to be paranoid about unexpected situations. As a result, attacks can be important even if they are not practical to exploit under real- world conditions. The attack described in this paper is similar; while there are quite a few preconditions for mounting the attack, this does not make the research unimportant or mean that people should ignore the work. Specific requirements to mount the attack include:

• The session has to use CBC mode. The vast majority of SSL connections use RC4, for which the attack is not applicable. Because of the algorithm negotiation used in SSL/TLS is secured in the initial handshake, man-in-the- middle attackers should not be able affect the outcome of the algorithm selection process.

• The attacker has to act as an active man-in-the-middle attacker. Passive eavesdropping is not sufficient.
• The server's SSL implementation has to be vulnerable (see #3 below). The protocol also has to be oblivious to repeated failures.

• The target protocol also has to have some very specific characteristics that allow the adversary to form the right kinds of messages. For most uses of SSL (e.g., normal web browsing), this type of attack does not generally apply.

3. Can affected implementations be fixed? Yes. OpenSSL has been updated (http://www.openssl.org/news/secadv_20030219.txt). For more information, also see http://www.openssl.org/~bodo/tls-cbc.txt. I don't know what other vendors/projects are doing.

4. Is this an issue for the client or the server? Normally, this would only be an issue for the "server" (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections.

A couple of final comments:

I'm constantly amazed by the number of ways that it's possible to screw up security. Overall, SSL 3.0 seems to have aged well, but I wish I'd done a better job of handling errors in the design. In particular, error handling was involved in both of the attacks against SSL that I consider non-obvious, notably Bleichenbacher's attack and CBC-padding attacks such as this one. While these types of attacks weren't known when I was designing SSL 3.0, I generally wish I'd provided less information in error messages.

Finally, I also want to give thanks everyone who has helped to study SSL's security, contributed to implementations, and helped shepherd it through the standards processes."

in4mation writes "The folks at LASEC have found a flaw in the SSL protocol. Quoting Professor Serge Vaudenay from a BBC article the security problem is in 'the SSL protocol itself and not in how we use it or how we implement it.' Apparently the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack." Update: 02/20 20:52 GMT by T : Kurt Seifried writes to say that this is almost exactly wrong: "The flaw is in IMPLEMENTATION, NOT THE PROTOCOL. Due to the way error checks are handled an attacker can find out which error condition occurred by measuring the response. The solution is trivial, a path that forces OpenSSL to do the second check even if the first one fails, thus denying the remote attacker any information as to which exact error condition occurred." He includes a link to the security advisory at openssl.org. Update: 02/20 21:49 GMT by T : Read on below for some more information from SSL 3.0 designer Paul Kocher.

Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:

The referenced paper (http://lasecwww.epfl.ch/memo_ssl.shtml) describes how timing variations in SSL/TLS implementations can be used in certain situations to slowly gather information about encrypted data. If the certain conditions are met, the attacker can decrypt some information from the message (e.g., a password). Strictly speaking, the fact that implementations reveal sensitive information in timing channels is an implementation issue, not a flaw in the underlying cryptographic protocol. This doesn't make the issue unimportant, however, and timing attacks are big deal for implementers because they are easy to introduce, notoriously tricky to detect, and often difficult to eliminate.

Answers to general questions:

1. Is it still okay to send my credit card number over SSL? Yes. This attack is not applicable to web shopping and there are much easier ways that fraudsters steal credit card information (e.g., breaking into merchants' web sites -- a problem that SSL can't solve). In any case, the bank is generally responsible if someone steals your card info.

2. Is the paper "real" or another bogus "I broke SSL" claim? The paper is legit. The Slashdot announcement suggests that SSL itself is broken, however, which is a bit misleading.

2. Is this a practical attack to exploit? Cryptographers need to be paranoid about unexpected situations. As a result, attacks can be important even if they are not practical to exploit under real- world conditions. The attack described in this paper is similar; while there are quite a few preconditions for mounting the attack, this does not make the research unimportant or mean that people should ignore the work. Specific requirements to mount the attack include:

• The session has to use CBC mode. The vast majority of SSL connections use RC4, for which the attack is not applicable. Because of the algorithm negotiation used in SSL/TLS is secured in the initial handshake, man-in-the- middle attackers should not be able affect the outcome of the algorithm selection process.

• The attacker has to act as an active man-in-the-middle attacker. Passive eavesdropping is not sufficient.
• The server's SSL implementation has to be vulnerable (see #3 below). The protocol also has to be oblivious to repeated failures.

• The target protocol also has to have some very specific characteristics that allow the adversary to form the right kinds of messages. For most uses of SSL (e.g., normal web browsing), this type of attack does not generally apply.

3. Can affected implementations be fixed? Yes. OpenSSL has been updated (http://www.openssl.org/news/secadv_20030219.txt). For more information, also see http://www.openssl.org/~bodo/tls-cbc.txt. I don't know what other vendors/projects are doing.

4. Is this an issue for the client or the server? Normally, this would only be an issue for the "server" (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections.

A couple of final comments:

I'm constantly amazed by the number of ways that it's possible to screw up security. Overall, SSL 3.0 seems to have aged well, but I wish I'd done a better job of handling errors in the design. In particular, error handling was involved in both of the attacks against SSL that I consider non-obvious, notably Bleichenbacher's attack and CBC-padding attacks such as this one. While these types of attacks weren't known when I was designing SSL 3.0, I generally wish I'd provided less information in error messages.

Finally, I also want to give thanks everyone who has helped to study SSL's security, contributed to implementations, and helped shepherd it through the standards processes."

Mike Clark writes "There are many security books on the shelves today. Most of them describe the same hacker tools and methods. They don't get very technical and once you've read one, you've read them all. Building Open Source Network Security Tools is a different breed of security book." Read on for the rest of Mike's review. Building Open Source Network Security Tools author Mike D. Schiffman pages 424 publisher John Wiley & Sons rating 9 reviewer Mike Clark ISBN 0471205443 summary How to use open source libraries, such as libpcap and libdnet, to build network security tools.

Building Open Source Network Security Tools , just as the name suggests, is about how to build network security tools. This is a technical book, so you are going to have a little knowledge of C and your networking principles. This is definitely not a manager's book.

First the book describes some basic principles in developing security software. This is a quick primer in case you have never been involved in software development. Next the book goes on to describe several commonly used libraries like libnet and libpcap. For each library, the structures and functions are explained, then there is sample code. I have written programs using libpcap and libnet before, and I still learned something. There is even a section on OpenSSL programming. OpenSSL is a rather large and cryptic, no pun intended, library (in my experience anyways). This book sheds some light on it! These chapters are a great reference to have when making a new security tool.

The author then goes on to explain the several techniques like attack and penetration and active reconnaissance. Not only does the author tell you how they would in a technical sense, he provides code that does it, and explains each piece. This is very useful since most tools in the wild aren't very well commented ;) There is also a chapter on buffer overflows and format string vulnerabilities. These chapters are very well done and do a good job in explaining how they work and how to write code to use them. It may sound like this is an offensive hacker book, but it also gives examples on how to write defensive programs, like a port scan detection tool. At the end of the book the author ties it all together with a large program that utilizes many of the techniques mentioned in the book.

I found this book to be very refreshing. I had been waiting for a good security programming reference, and this is it. As a part of the Honeynet Project, I have seen a large number of compromises and tools, and one thing I've found is that in order to truly know who your enemy is, and how they operate, you need to know how their tools work. I wish this book had been released years ago when I first became interested in network security. It would have saved me from stumbling around old web pages and dead links. If you're an information security professional, this book is a must have for your library.

You can purchase Building Open Source Network Security Tools from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Kataire writes "C|Net posted this story about how Sun Microsystems' has donated 'elliptic curve' encryption technology, (developed by Whitfield Diffie of Diffie-Hellman public key fame) to the OpenSSL project. This potentially means better encryption for lighter-weight systems such as PDAs."

sverrehu writes "A GNU/Linux worm exploiting a bug in OpenSSL spreads through vulnerable Apache web servers, according to Symantec. The worm, which was first reported in Europe, targets several popular Linux distributions. See also the SecurityFocus vulnerability listing for the OpenSSL bug." sionide also writes: "Netcraft recently published a report which explains that a large portion of Apache systems are still unpatched (halfway down). To protect yourself please upgrade to OpenSSL 0.9.6g."

Pseud0 writes "Just announced on the OpenSSL announce mailing list. The affected versions are "[...] OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable." Get your updates here."

Pseud0 writes "Just announced on the OpenSSL announce mailing list. The affected versions are "[...] OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable." Get your updates here."

Pseud0 writes "Just announced on the OpenSSL announce mailing list. The affected versions are "[...] OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable." Get your updates here."

Skapare asks: "A year ago, this question about using Apache and SSL in a commercial environment was asked in the Apache section of Slashdot. The RSA patent was still in force back then, and the focus was on commercial products like Raven. Since then, the RSA patent has been released and then expired. That same month a year ago, Ask Slashdot also featured a question about encumbrance of SSL/PGP. But with the RSA patent gone, and Diffie-Hellman before it, this surely opens up Apache with SSL free for commercial use. Now I'm exploring options for free SSL for Apache, and note at least two choices, Apache-SSL, and mod_ssl. What I'd like to ask is what are the fundamental and principle differences between these free versions that I should consider in deciding which I should use in a commercial environment."

EraseMe asks: "I have a great idea for an open source project, but I don't know where to begin. I'm tired of paying large cash for SSL Certifications from companies such as VeriSign. It would be great to provide companies and individuals with free certifications, with one central server providing the solution. I would imagine this wouldn't be terribly difficult to implement over exisiting applications such as OpenSSL and mod_ssl." This would be a cool idea, but if the certs are free, how would such an entity stay afloat and pay for things like servers, office space and bandwidth?