Update 7 (May 26, 2014): Further changes were required to fully resolve the security vulnerability known as Heartbleed. Update 6 (April 22, 2014): An ebf/SP has been posted to the download site for version 12.0.1 and version 16 on Windows and Linux platforms that resolves this vulnerability. The fix will be released on other platforms as soon as internal testing is completed. Update 5 (April 21, 2014): An ebf/SP has been posted to the download site for version 16 on Windows platforms that resolves this vulnerability. The fix will be released on other platforms as soon as internal testing is completed. Update 4: Ten days since discovery, no EBFs yet, no news for a week. Update 3: There is some discussion of Heartbleed on sap.com; google this: heartbleed site:sap.com Update 2: E-filing of Canadian taxes shut down due to Heartbleed bug Update: For the record, current builds of SQL Anywhere use OpenSSL: What impact will the switch to OpenSSL have on SQL Anywhere strong encryption? Also: Heartblead is a real zero-day vulnerability with its own website: heartbleed.com (highlighting added) Common Web Encryption Tool Is Flawed, Researchers Say Bug, Nicknamed Heartbleed, Potentially Exposes Masses of Sensitive Data By DANNY YADRON - Wall Street Journal Updated April 8, 2014 7:29 p.m. ET An encryption tool used by a large chunk of the Internet is flawed, potentially exposing reams of data meant to be hidden from prying eyes. The bug, nicknamed Heartbleed by researchers at Google Inc. and cybersecurity firm Codenomicon, could have affected two-thirds of active websites when it was disclosed Monday, they said. On Tuesday, website operators, including Yahoo Inc., YHOO +2.30% raced to fix the problem. A Yahoo spokeswoman said the company had "made the appropriate corrections." Several researchers said earlier that they had been able to capture Yahoo usernames and passwords. Many other major websites, such as Google, Amazon.com Inc. AMZN +2.93% and eBay Inc., EBAY +3.49% appeared to be safe, based on a test created by a researcher for cybersecurity company Qualys Inc. QLYS +1.66% The bug exploits a problem in certain versions of OpenSSL, a free set of encryption tools used by much of the Internet. OpenSSL is managed by four core European programmers, only one of whom counts it as his full-time job. The limited resources behind the encryption code highlight a challenge for Web developers amid increased concern about hackers and government snoops. Websites increasingly use encryption to mask data such as usernames, passwords and credit-card numbers. That prevents a hacker lurking at a coffee shop from grabbing personal information out of the air as it travels to a wireless router. This type of encryption is called SSL, or secure sockets layer, or TLS, or transport layer security. When a website is using these forms of encryption, a padlock appears with the Web address in a browser. Web servers that use the affected versions of the code store some data unprotected in memory. Hackers can grab that data, and reconstruct information about users or keys that would allow them to monitor past or future encrypted traffic. "Anyone can reach out to the Internet and scoop out of the data," said Thomas Ptacek, a researcher at Matasano Security in Chicago. "I can be in my office here. I can be in Estonia." Writing encryption code is complex, so many website operators tap OpenSSL, which is free. It was created in the late 1990s by developers who wanted an easy-to-use encryption scheme for Internet traffic. Its website is bare bones, as are its finances. Steve Marquess, president of the OpenSSL Software Foundation, a separate entity that solicits funding for the team that manages the code, said its 2013 budget was less than $1 million. "There's no question more effectively applied manpower would be a good thing," said Mr. Marquess, 59 years old. "Formal code audits would be a good thing." Mr. Marquess, a former Defense Department consultant who works in Maryland, is the project's only U.S. resident. The other coders are based in Europe to avoid export laws for advanced encryption. Still, OpenSSL has become synonymous with online encryption. The Defense Department and Department of Homeland Security use OpenSSL, Mr. Marquess said. On its website, Amazon suggests that customers of its Amazon Web Services remote-computing service use OpenSSL when adding encryption to their webpages. In a blog post, Amazon said it expected to have mitigated the issue for all AWS users by the end of Tuesday. Ivan Ristic, a Serbian researcher for Qualys, spent much of Monday creating a tool to test whether a website is affected. Traffic to Mr. Ristic's webpage was up seven-fold Tuesday as Web users checked the security status of various websites, he said. The researchers said the bug had existed in the encryption code for roughly two years. They pointed users to a patch and explained how website operators can protect themselves and their users. Much of the Internet appeared to be caught off guard by the disclosures. "If you need strong anonymity or privacy," Roger Dingledine, president of the Tor Project, a web service used to obscure Internet users' identity, wrote in a blog post, "you might want to stay away from the Internet entirely for the next few days while things settle." asked 08 Apr '14, 20:32 Breck Carter Jason Hinspe... |
I've posted to the SQL Anywhere Community on SCN detailing the vulnerabilities caused by Heartbleed as well as suggested workarounds and resolutions for the problem http://scn.sap.com/community/sql-anywhere/blog/2014/04/11/openssl-heartbleed-and-sql-anywhere answered 11 Apr '14, 14:56 Jason Hinspe... So SQL Remote over HTTPS would be affected in the relevant versions, too, as it does use web services internally?
(11 Apr '14, 15:19)
Volker Barth
Replies hidden
Technically, yes, but this would be difficult to actually do, for a variety of reasons I can't explain here.
(11 Apr '14, 15:58)
Jason Hinspe...
What about On Demand 1.0.4613 (SP3) for Windows and Linux? ...are they affected?
(11 Apr '14, 16:08)
Breck Carter
Replies hidden
No, SAODE SP3 is not affected, since it did not use OpenSSL. SAODE SP 4 will be affected.
(11 Apr '14, 16:25)
Jason Hinspe...
This issue is also documented as KBA #2004769.
(11 Apr '14, 16:27)
Jeff Albion
Just a comment on the text on the SCN page: The paragraph
seems to appear twice - am I right that this is a deliberate "double reminder"?
(14 Apr '14, 05:20)
Volker Barth
Replies hidden
Well, truth be told it was a cut and paste error, but I like your explanation better :)
(14 Apr '14, 09:39)
Jason Hinspe...
|
Just to let everyone know - we aren't ignoring this question. answered 09 Apr '14, 13:38 Jason Hinspe... Does the Standing Committee To Discuss Heartbleed have any meetings planned?
(11 Apr '14, 12:13)
Breck Carter
Replies hidden
Until a communique is published, I'd recommend that summary:
(11 Apr '14, 12:34)
Volker Barth
|
In my (limited) understanding, it's more than that: In case key material has been compromised (as expected), this may be misused in the future even if the according sites will have fixed the OpenSSL bug soon. Arrh, I should better quote from that site:
FWIW, I guess if you have installed these newer SQL Anywhere versions without the (separately licensed) FIPS encryption mode, the OpenSLL libraries are not installed at all. Just my 2 cents.
CAVEAT, the free developer edition (when EBF'ed) will usually contain these files.
> if you have installed these newer SQL Anywhere versions without the (separately licensed) FIPS encryption mode, the OpenSLL libraries are not installed at all.
How did you reach that conclusion?
I don't have FIPS installed, but my copy of 16.0.0.1823 does contain the following files dated 2014-02-19...
...which look suspiciously like they might have something to do with OpenSSL :)
Well, I have checked against the v16 docs - particularly the "change to OpenSSL / deployment" issue - and there only these files are mentioned:
But apparently I have far less important titles than Jason, so I'll wait for an official statement, too:)
AFAIK OpenSSL applies to non-FIPS encryption as well. The files you list are "new files" as in "additional files" because the topic you refer to is a "what's new" rather than a full description of deployment... the full list in Encryption deployment includes dbrsa16.dll among others.
Yes, but the files like dbrsa16.dll have already been there before the switch to OpenSSL has happened (and are part of v10 and v11 with their according name variante dbrsa11.dll and the like). Therefore I would conclude they are not part of the SQL Anywhere OpenSSL support. - Just my guesswork, needless to say.
The docs state that "Strong encryption in FIPS, TLS, and HTTPS now achieved using OpenSSL".
The docs state that dbrsa16.dll is required to deploy Transport Layer Security encryption.
Therefore, it is clear that new copies of the non-FIPS component dbrsa16.dll delivered with recent SQL Anywhere 16 EBFs ARE part of the SQL Anywhere 16 OpenSSL support.
Whether SQL Anywhere is affected by Heartbleed is an open question, but it is clear that OpenSSL is used for more than FIPS encryption... the docs say so.
What a rich discussion we have, Breck - to bridge the time until the folks with the code are ready to communicate the truth...
To cite Graeme from this FAQ...
Fine . . .
Thanks for your edited comment, I have omitted the clue-less hint:)
And to be clear: I was absolutely relating to myself, as well, simply as I don't know the facts. I'll keep silent now and wait for the official notification:)
That question was specifically talking about database encryption, for which we use our own implementation of AES/AES256 unless you're using FIPS. For TLS, we use OpenSSL in both the FIPS and non-FIPS cases. Breck is correct; dbrsaX.dll is statically linked with OpenSSL.
Thanks for the clarification.
I'm somewhat irritated that my SA 16.0.0.1823 and 12.0.1.4085 installs do not contain the new DLLs but do contain dbrsaX.dll and the like - do I have to conclude something is gone wrong here? (Note, I don't use TLS nor FIPS mode here.)
You're frugal, that's what's wrong... you haven't paid for FIPs**t :)
The new DLLs (libeay32.dll, ssleay32.dll on Windows) are only for FIPS.
OK, given all that, I'll proudly accept the "I am the completely clueless one" tag:)