Talk:OpenSSL

Merge SSLeay

I propose we merge in SSLeay. Unless we expect to be writing a large article on it, I suggest it'd probably be better off described in a paragraph in this article in a "History of OpenSSL" section. — Matt Crypto 22:58, 29 January 2006 (UTC)

I guess there's noone disagreeing with you on this one. Feel free to merge, or I will some time in the future. Janizary 01:09, 8 February 2006 (UTC)

Merge OpenSSL exception

This really should just be a section in the OpenSSL article after all. 65.95.229.9 01:06, 25 March 2006 (UTC)

I'm all for it, they are all directly linked together anyways. —Preceding unsigned comment added by 198.169.188.225 (talk • contribs)

Well, SSLEAY is a part of OpenSSL, so why not merge it. --70.155.60.59 21:38, 15 June 2006 (UTC)

No, OpenSSL is derived from SSLeay - there is a significant difference, besides which I already did that merge. Janizary 23:55, 15 June 2006 (UTC)

FIPS 140-2

I think it was a mistake to revoke it. And they put it back again. See: http://it.slashdot.org/it/06/07/19/1410243.shtml

Links

The links are too focused on the GPL exception. There should be more/better links on OpenSSL itself.

dead link

• wget's readme file, including the GPL with exception

This link is dead. I did not find any recent link to replace it with, therefore I am copying it here. David Andel 15:29, 27 August 2007 (UTC)

Their repository now appears to be hosted here. -- Bovineone 18:57, 27 August 2007 (UTC)

Undue weight and coatracking

Right now, well over 50% of the article consists of arguing about the OpenSSL license terms. This is clearly an example of undue weight under Wikipedia policy, and it also violates our guideline against coat racks. Much of the discussion is original research as well. This section needs to be drastically trimmed. *** Crotalus *** 07:49, 2 January 2008 (UTC)

I've taken a hatchet to the article and removed the {{coatrack}} template. Hope thats OK. --Salix alba (talk) 22:45, 4 January 2008 (UTC)

OpenSSL exception

The section on OpenSSL exception (which apparently according to this discussion page was merged from a separate article) is completely unclear. It would be nice to be able to read the history for the deleted (merged) article. How can an operating system vendor (or organization) grant an exception to a license for someone else's intellectual property? That may not be the meaning of this exception, but as I said it is not clear at all what this section is talking about. Anyone have the access to the original pre-merged article text. 84.122.211.84 (talk) 21:40, 26 April 2008 (UTC)

Important -> the GPL "system exception" does not give more rights to combine other code with GPLs code. It only allows to omit the code in question from the "complete source" to recude the size of the source archives.

Debian security breach

Re the recent additon to this section ("The discussion on the Debian bug tracker leading to this change reveals, however, that the access of uninitialised memory has been a persistent bug in OpenSSL which has not been fixed.[1]"): This is misleading. Even if the source showed what the addition claims it does, this would not support the assertion that "access of uninitialised memory is a bug in OpenSSL", only that in the Debian maintainer's opinion, use of uninitialised memory is a bug -- an opinion clearly not shared by the OpenSLL devs (who, if this episode demonstrates anything, know considerably more about OpenSLL than the Debian maintainer). And, to my reading of the page, it does not even show that: the only person claiming that it is a bug for end-users of the package was the original submitter, Richard Kettlewell, who is not the maintainer; Roeckx made the change in order to make debugging easier. Also, the other addition ("it is still a bug since it could potentially lead to Undefined_behavior") is equally suspect and unsourced: I have not seen any suggestion that undefined behaviour could result from using unitialised memory for entroy (Sure, the contents of memory will be different each time; but then so will the contents of /dev/urandom -- that's rather the point). -- simxp (talk) 10:56, 30 August 2008 (UTC)

I agree that the OpenSSL developers have the opinion that their code is not buggy. However, I assert that this is just an opinion and the current formulation of the WP article gives the impression that this is not an isolated opinion, but a fact. Valgrind, no the other hand, lists the use of uninitialised memory as a bug that it can detect. Googling "uninitialised memory exploit" furthermore lists a considerable collection of security holes that even the respective vendors consider bugs which required and require fixing. Even if we assume that OpenSSL's usage of uninitialised memory does not constitute a bug, the fact that code linked against it cannot be checked for memory leaks with a popular tool like Valgrind without lots of spurious error messages would be called improper behavior by many (if not most) people. Nonetheless, the content of uninitialised memory could in theory be just the XOR of the /dev/random buffer in which case the entropy would be substantially reduced. This is not the case on most current implementation systems, but just because it has worked so far doesn't make it correct. Finally, there has not been a way (and there still is not) to test and verify the quality of the generated random numbers due to the absence of a certification procedure in OpenSSL. If something like this was in place, the bug would not have gone undetected. I do not know, however, how to properly source the absence of such a feature in a WP article.

The objections which I still have against the current version of the article are: a) it gives the impression that the opinion of the OpenSSL developers (that their code is not buggy) is an undisputed fact, b) the reader does not learn about the problems the behavior creates even if one assumes OpenSSL is valid code, and c) that OpenSSL has no means of validation and certification of generated keys. I do admit that I don't know how to write c) in a neutral POV manner with some good source - if you do, I would be grateful. However, I do believe that a) and b) should be incorporated in the text in order to ensure a neutral POV and not just reflect the isolated opinion of the OpenSSL developers. 119.14.24.157 (talk) 06:48, 31 August 2008 (UTC)

I've just read through the section again, and I have to disagree: the current paragraph, as far as I can see, in no way presents any such opinion (that OpenSLL is not buggy), and certainly not as "undisputed fact". It presents the reason the Debian maintainer made the change ("To make it easier to debug C applications that use the openssl libraries"), taken from the Debian wiki, and explains that, done correctly, such a change "should not affect [the] security [of OpenSSL]". It gives no opinion either way as to which version -- the OpenSSL version or what the Debian version would have been if the change had been done correctly -- would be more correct or less buggy.

With regards to "I do not know ... how to properly source the absence of such a feature in a WP article", the answer is, the same way as you would source anything else: if reliable sources exist that have published such a criticism of OpenSSL, then write it up in the appropriate section. But, to be honest, I don't follow your criticism of OpenSSL's certification: it is certified (by NIST), but such certification would not (and did not) catch the issue in question, since it tests OpenSSL's OpenSSL rather than Debian's OpenSSL. You also mention the lack of a way to "verify the quality of the generated random numbers", but OpenSSL doesn't generate its own random numbers; it uses an MD5 of output from /dev/urandom; and so is reliant on the quality whatever PRNG the underlying OS uses; which can (and should) be tested and certified seperately.

(As a side point, your assertion that "The content of uninitialised memory could in theory be just the XOR of the /dev/random buffer in which case the entropy would be substantially reduced" is highly misleading. XORing random or pseudorandom data with any other data will not affect entropy (as long, of course, as you have independence -- i.e. the other data was not based on the random data or psedorandom seed). I could consistenly xor everything that comes out of /dev/urandom with the complete lyrics of Happy Birthday, and neither you nor any statistical tests would be able to tell the difference. Yes, certainly the contents of uninitialised memory could, by chance, happen to be the XOR of /dev/urandom -- but the chances of that happening is exactly the same as, for example, /dev/urandom producing all nulls; which is to say 1/2 to the power of the number of bits in question. That's inevitable.) -- simxp (talk) 14:57, 31 August 2008 (UTC)

You are absolutely correct about the random number generator - OpenSSL is not responsible for it. Sorry, my mistake. I should have written about the lack of a way to "verify the quality of the generated keys", not the random numbers (since the RNG was clearly not the problem). So a way to phrase the problem would be "I have compiled the OpenSSL library on my system and want to know how good the generated keys are". I am not aware of an answer to such a request.

I managed to find another link to an email response from the OpenSSL developers [[2]] . The email comes from an OpenSSL developer and approves the changes in both lines of code, claiming that the effect on the entropy would be "not much". The fact that this exchange was just mailed privately and not brought to the attention of a larger group of OpenSSL developers is an issue with their bug tracking and fixing procedures. (Had a larger group of developers been aware of it, they might have protested and stopped the change.)

On the contents of uninitialised memory: your assumption is that there is zero correlation between the content of uninitialised memory and the output of the random number generator. In this case, it would indeed not pose a problem. However, because the status of uninitialised memory is undefined that correlation might also be -1. There is no reason why some platform should not have a buffer for random numbers and use it to fill uninitialised memory with the xor of the content of the buffer, i.e., the upcoming random numbers on the next read from /dev/urandom. While the assumption of no correlation sounds natural and most likely is true in most implementation systems, it is nonetheless an additional assumption which - when violated - can compromise the *generated keys* even in the presence of good random number generators. 119.14.24.69 (talk) 04:26, 1 September 2008 (UTC)

[Edit:] The link is apparently not a private mail, but was sent to the official OpenSSL-developers list. So there was no protest against it and the change has in fact been approved by the OpenSSL developers. 122.99.62.213 (talk) 23:48, 1 September 2008 (UTC)

explanation

BADLY DONE! total gibberish to anyone who does not have a degree in computer whatevering!

WHAT is it - example: limewire is a p2p program

                                       OPEN SSL IS ????

WHAT is it USED FOR - example: limewire permits sharing of several types of files over the internet

                                                            OPEN SSL DOES???????????  

this appeared recently on my computer, thus i have NO idea what it is used for, why and how it was installed etc. or whether this should or can be removed. and going online to try to find some CLEAR and STRAIGHTFORWARD information is a laughable task. —Preceding unsigned comment added by 76.67.124.201 (talk) 21:02, 4 July 2010 (UTC)

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

Dear Badly, Please re-read the article.

Viz: OPEN SSL IS??? "OpenSSL is an open source implementation of the SSL and TLS protocols."

Viz: OPEN SSL DOES??? ". . .implements . . . basic cryptographic functions"

Especially, re-read the linked articles about SSL and TLS protocols.

Unfortunately, even in an encyclopedic source like Wikipedia, there has to be some presumption of domain knowledge to prevent articles from becoming unwieldy. An article on n-mutexes has to presume a knowledge of both programming and statistics, because it would be - literally - impossible to explain if it were necessary to describe everything from binary logic on up. Journals on Quality Engineering assume a domain knowledge of statistical analysis. Pilots, in their conversations, don't have to explain what the rudder pedals are for.

One of the advantages of Wikipedia is that interesting and informative articles - helping to explain the article in question - can be directly hyperlinked. You should try following some of them, it will be an enlightening experience.

Jim (JR) 24.107.232.143 (talk) —Preceding undated comment added 05:08, 2 October 2010 (UTC).

Does OpenSSL support ECIES ?

If you could resolve this problem, please posted it. —Preceding unsigned comment added by 219.87.128.204 (talk) 11:39, 9 September 2010 (UTC)

past tense?

Why is the Heartbleed bug written as if it does not exist anymore? CapnZapp (talk) 05:26, 9 April 2014 (UTC)

The actual vulnerability has been fixed in the latest version of OpenSSL; strictly speaking, the bug no longer exists. However, private keys stolen before the fix was published remain a serious problem, especially if the server does not implement perfect forward secrecy. Since there is no way to determine whether a key has been stolen, it is necessary to revoke and reissue the certificate, and other mitigation, such as forced password changes, may also be required. --NYKevin 05:53, 9 April 2014 (UTC)

Sorry, you gave me a technical answer particular to this piece of software when I was fishing for a correction to wiki policy on how we write articles. Much better now. CapnZapp (talk) 11:39, 9 April 2014 (UTC)

XKCD

Today's spike in page accesses must be due to this XKCD. Maproom (talk) 06:08, 9 April 2014 (UTC)

Maybe. Or it could be the fact that the Heartbleed story is suddenly all over mainstream media reports, and this article is linked from the ITN section on the Main Page. xkcd is not the only thing that drives traffic. Modest Genius ^talk 10:32, 9 April 2014 (UTC)

Heartbleed chronology?

I'm mystified. Wiki has this "heartbleed" OpenSSL vulnerability announcement on it's main page as headline news; Slashdot hadn't mentioned it, the announcement was one day ago? But there is an XKCD about it already (see above) and the bug is cited in its own domain www.heartbleed.com How can a bug have such superb marketing? What is the actual technical source for the bug? I'd dismiss it as a hoax if it were not for the xkcd; I suspect that something that has been known for awhile has suddenly gotten press. Pete St.John (talk) 00:08, 10 April 2014 (UTC)

Here's the official OpenSSL security advisory. [3] It is cited in the "History" section of Heartbleed bug. --NYKevin 13:59, 10 April 2014 (UTC)

Thanks. I just want to note that the article you point to didn't exist yesterday. So really the news to me, is not so much the bug, but this abrupt spike regarding it. The heartbleed.com site doesn't cite anything and doesn't even have webmaster contact info, so while the bug evidently is real the reaction is suspicious to me. (Also I corrected a typo in "heartbleed" above) Pete St.John (talk) 16:49, 10 April 2014 (UTC)

Not to mention that it has a f**** logo! Is this a Codenomicon PR-stunt? — Preceding unsigned comment added by 84.130.164.211 (talk) 23:04, 10 April 2014 (UTC)

lede

I think it would be good to add answers to the 6 journalistic W's into the lede.--Wuerzele (talk) 22:37, 14 April 2014 (UTC)

While I think that the Lead section could use some work, I think that most of the W's are either covered or irrelevant.

Who	The OpenSSL project.	(That could be added into the lead.)
What	An implementation of the SSL and TLS protocols.	(Already in lead.)
Where	The internet, I guess. The project managers are in Europe, and much of the funding comes from the U.S.	(Perhaps that could be added into the lead, but it seems more germane to an article about the OpenSSL project, rather than the library itself.)
When	1998-present.	(Not sure that this is relevant to the lead.)
Why	The OpenSSL project was founded in 1998 to invent a free set of encryption tools for the code used on the Internet.	(This sentence was taken from the first section. It could be modified and copied into the lead.)
How	C.	(Already in lead.)

Furthermore, the Lead Section Manual of Style neither endorses nor rejects the 5 W's (See the "comparison to news style" section). It is also useful to note that the 5 W's were developed for reporting events, not writing encyclopedic entries for concepts or things. Given the above, I would argue that covering the 5 W's simply for the sake of completeness wouldn't be terribly beneficial to the article, but adding some of the W's would.

WhoIsSparticus (talk) 01:46, 24 June 2014 (UTC)

When I hover over the OpenSSL link in wikipedia I see the heartbleed logo

I think that's a bit harsh for OpenSSL, can we perhaps remove that logo? Opalraava (talk) 21:09, 11 January 2015 (UTC)

I am assuming that you are using the Hovercards beta feature as this does not appear to happen to the Navigation popups gadget. From the Hovercards discussion page it list the following known issue First image is not always used due to image proportions, size, or quality. PaleAqua (talk) 03:35, 12 January 2015 (UTC)

Project history

"The OpenSSL project management team consists of four Europeans." - what's the purpose of this sentence other than to show its authors xenophobic/ignorant character? — Preceding unsigned comment added by 2001:8A0:EC5F:8501:D0E9:641B:5D21:6562 (talk) 14:13, 25 January 2015 (UTC)

OpenSSL vs OpenSSH

I've readded the distinguish headers between OpenSSL and OpenSSH. The two names are only one letter apart, there is or at least was confusion between the two projects. This can especially be seen by looking at some of the comment sections on news stores about the Heartbleed bug where commenters often conflated OpenSSL, OpenSSH and OpenBSD. PaleAqua (talk) 16:56, 5 September 2015 (UTC)

Hello! On second thought, I'm fine with those hatnotes – I guess that an average reader isn't super-careful and oriented toward details, :) so having the hatnotes should be actually beneficial. — Dsimic (talk | contribs) 17:25, 5 September 2015 (UTC)

The intro does adequately summarize its contents

I question the relevance of the note "This article's introduction section may not adequately summarize its contents."

I think the intro should primarily tell the reader /what/ OpenSSL is, and why it is notable. That is more important than "summarizing" the contents of the article. This article needed an accessible overview of what OpenSSL is, not an overview of the article's contents. (I have just added some words to improve that.)

Once the intro has told what OpenSSL is, there is not much more to say about that. A deeper discussion of encryption, authentication, and the SSL and TLS protocols belongs in articles not tied to one particular implementation. The particulars about the API are way too technical stuff for an encyclopedia.

The rest of the article contains supplementary informations about the subject. This may give the impression that the article talks about something else than the intro does.

The article contains a large section about the vulnerabilities of OpenSSL. Yet I do not think it would be appropriate to write about that in the lead. That would create an impression that OpenSSL is particularly riddled with holes. The flaws have general interest because so much depends on OpenSSL's security, not because OpenSSL is more flawed than other comparable software. If you want to add something about the flaws in the lead, one could perhaps write about how (in particular) the discovery of the heartbleed vulnerability became a wake-up call, creating awareness that the world had come to trust this fundamental piece of software and take its quality for granted.

One could add stuff about the adoption of this library if there are any sources. Otherwise a section about that will tend to be original research. One could add something about when the first feature-complete version appeared, but I suspect that was quite immediately since the basis in SSLeay was quite good already in 1998. One could add something about alternatives, or about what functionality has been added since the beginning in 1998. 11:56, 16 September 2015 (UTC)~ — Preceding unsigned comment added by Cacadril (talk • contribs)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified 5 external links on OpenSSL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for https://online.wsj.com/news/articles/SB20001424052702303873604579495362672447986
• Added archive https://web.archive.org/web/20150120120428/https://www.openssl.org/news/openssl-1.0.1-notes.html to https://www.openssl.org/news/openssl-1.0.1-notes.html
• Added {{dead link}} tag to http://cvs.openssl.org/fileview?f=openssl%2Fengines%2Fccgost%2FREADME.gost
• Added archive https://web.archive.org/web/20071010000622/http://www.gcn.com/online/vol1_no1/43142-1.html to http://www.gcn.com/online/vol1_no1/43142-1.html
• Added archive https://web.archive.org/web/20080102164139/http://users.ugent.be/~bpuype/wget/ to http://users.ugent.be/~bpuype/wget
• Added archive https://web.archive.org/web/20110212024627/http://www.climm.org/download.shtml.en to http://www.climm.org/download.shtml.en

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:22, 20 January 2018 (UTC)

April Fools Joke? OpenSSL Programming??

Did someone play a prank on Wikipedia by adding two false links? The link to the OpenSSL Programming Guide is a Hewlett Packard document on OpenVMS. The link to the Open SSL Programming Manual is a link to IBM's Linux documentation. Would someone in charge please correct this spam? Perhaps it was the same perpetrator that included OpenSSL in the page on Arbitrary-Precision Arithmetic software? Hpfeil (talk) 21:37, 27 April 2020 (UTC)

Licensing

Currently the page states:

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used

Dual license usually refers to the choice between licenses presented to the recipient of the software (OpenSSL in this case). However in the OpenSSl license text they refer to "double license":

The OpenSSL toolkit stays under a double license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit.

So I would argue for changing the above wikipedia text to:

OpenSSL was licensed under both the OpenSSL License and the SSLeay License, which means that the terms of both licenses most be adhered to

Hesa (talk) 13:57, 5 January 2023 (UTC)

I don't think any real difference was intended. A license for a piece of software S is a grant of the form, "If you comply with condition C, you may use S for purpose P." A dual/double license is then a statement, "If you comply with C1, you may use S for P1; and if you comply with [stronger, weaker, or incomparable] C2, you may use S for P2." The recipient still has the choice of which of the two clauses to use, depending on what they want to do, and what restrictions they are willing to accept. This gives them strictly more freedom than the combined license, "If you comply with both C1 and C2, you may use S for P1 and P2." Hqb (talk) 15:17, 5 January 2023 (UTC)

You wrote:

The recipient still has the choice of which of the two clauses to use

I read this is you're saying that the recipient has the choice of any of the two licenses (and the clauses/terms in there). If so, then I would say this is not what the OpenSSL page says. OpenSSL "double license...both the conditions of the OpenSSL License and the original SSLeay license apply". The recipient is not offered a choice between the licenses/terms/clauses. All must be complied with. Before going in to the wiki text (if/how to change) I think we need to agree on whether or not both licenses must be complied with or not. Hesa (talk) 14:59, 7 January 2023 (UTC)

Ah, I see: it's not that the original developer(s) re-released the software under a dual license, but that a new set of developers took over and added some further conditions of their own. Presumably the somewhat unusual "double license" formulation was adopted because the original license explicitly included the wording "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 GPL]." So I agree that, in this case, both sets of restrictions must be adhered to. Hqb (talk) 15:54, 7 January 2023 (UTC)

Collecting information and trying to connect the dots.

• OpenSSL (the software), version 1.0 and earlier
  • is released under the OpenSSL license, which refers to the two licenses "OpenSSL License and the original SSLeay license".
  • OpenSSL page at spdx has the old phrasing "under a dual license, i.e. both the conditions". So someone rephrased that to "double" (as in the logical AND) to avoid the word "dual" which usually means the logical OR
• OpenSSL (the software), version 3.0 and above
  • is released under Apache-2.0 and only that license. How they managed to switch license (rewrite the software, ask all (c) holders.... I do not know).
  • The developers did not add any restrictions to any of the license(s), they switched license from OpenSSL (really two licenses) to Apache-2.0

Hesa (talk) 23:02, 7 January 2023 (UTC)

Sounds right to me. (Except that it should probably be all the 1.x versions under the OpenSSL license, not only 1.0 and earlier.) And it seems that they did in fact (attempt to) contact all of the previous contributors in 2017 (more than 4 years before the first 3.0 release), but that the relicensing was still considered controversial by some. Hqb (talk) 10:53, 8 January 2023 (UTC)

Interesting links. Would you be able to add a bit of text and the two links above? I think they provide useful information about the OpenSSL project (as well as how a license can be changed).

Is my first initial text OK with you? Initial proposal:

OpenSSL was licensed under both the OpenSSL License and the SSLeay License, which means that the terms of both licenses most be adhered to

Hesa (talk) 16:54, 10 January 2023 (UTC)

And your point about 1.x is important. I think there's a 1.1.1s (or similar) out now, under the OpenSSL license. Can you add that? Hesa (talk) 16:55, 10 January 2023 (UTC)

I think you should just boldly go ahead and make any changes you deem appropriate. I have no particular further insights or knowledge about the matter; and if anyone objects, we can revisit any tricky points here. But I imagine that, as more as more users migrate to the 3.0 version, the 1.x licensing will become mainly of historical interest, rather than a practical concern. Hqb (talk) 18:23, 10 January 2023 (UTC)

Redundancy in ASN.1 parsing paragraph

The section "Denial of service: ASN.1 parsing" looks like it has a redundant sentence, but the two sentences seem to be in conflict with each other. Not sure which version is more accurate. Quesoteric (talk) 07:14, 11 February 2024 (UTC)