6 ms·

It still doesn't get at two top points of meta: TLS is a horribly overfeatured, design-by-committee standard AND C makes it incredibly easy to screw up and so r

It still doesn't get at two top points of meta: TLS is a horribly overfeatured, design-by-committee standard AND C makes it incredibly easy to screw up and so requires zealous attention to a defensive coding style to introduce fewer flaws.

cynicalkane 13y ago
It's possible to defensively code in C, particularly with modern tooling (some of which lets you write provably secure code) and good process. The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Like most people, I see Heartbleed as a process failure; unlike most people, I think the process failure goes far beyond TLS or OpenSSL or C.
- ahomescu1 13y ago
  > The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Sure, but open source developers have no obligation whatsoever to anyone. Considering they're not being paid in any way for their code, they can write whatever code they want and under whatever process they like. The problem IMHO is that OpenSSL was used for highly sensitive commercial uses (like Gmail, Amazon and others); I think responsibility should fall on companies who used the library without checking it first (Disclaimer: I'm not in anyway associated with OpenSSL or any crypto library, this is just how I see things).
  - userbinator 13y ago
    > I think responsibility should fall on companies who used the library without checking it first Agreed. The OpenSSL license (as do many others), has this very clear (if somewhat hard-to-read) disclaimer in it: "IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
    - cynicalkane 13y ago
      This is a standard disclaimer in software. It's just there so you can't sue. It doesn't mean OpenSSL was not intended to be a security library for everyone to use, because it obviously was. I don't like the 'amateur defense' of open source. No, people are not legally liable for code; no, no open-source dev has any obligation to write good code; but OpenSSL is still garbage. As long as you're writing code and using other peoples' code, you might as well care about craftsmanship. If you don't care about craftsmanship, maybe this is the wrong approach to a critical security library.
      - RyanZAG 13y ago
        > but OpenSSL is still garbage. What? Come on. Get a grip on reality. The code is some of the most efficient and widely used. I think it's also the only code that implements the entire spec. It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one.
        sillysaurus3 13y ago
        It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one. It's nothing like that at all. A piece of code's popularity is no evidence of its quality. Otherwise we'd never have advanced beyond BASIC. Implementing an entire spec is nothing to be proud of. Specs are often over-engineered. This is almost certainly the case for TLS. It's 103 pages long: http://tools.ietf.org/html/rfc5246 http://tools.ietf.org/html/rfc5246 We should be questioning the foundations we've been relying on until now when a single vulnerability was able to compromise most of the internet, possibly since 2011.
        bostik 13y ago
        > The code is some of the most efficient and widely used. Efficient, yes. Throughput in general is not a problem. Widely used, well... yes to that too. Although in this regard I would attributed a good chunk of it to inertia. When (common) use of cryptography started to take off around the time of the browser wars, there weren't too many options around. Web servers needed a way to serve protected content, and there was OpenSSL. Not just available, but already supported by language bindings and relatively easy to set up thanks to mod_ssl. First mover advantage + network effects + the fact that getting crypto right is really hard. If you wanted to unseat OpenSSL, you would need to overcome the fact that despite all the bad rap and the butt-ugly, and the leaky API, it was still getting the most exposure and field testing. Unlike some newcomer library, OpenSSL has the advantage that it is firmly embedded in the software ecosystem, and it has benefited from more than a decade of bugfixes. (I still remember when the timing attack for extracting RSA keys was discovered. The bug was pretty much everywhere, and not just in OpenSSL.) The widespread use of the library boils down to a simple and womewhat depressing fact: OpenSSL is used everywhere because OpenSSL is used everywhere. Replacing it with something better will be a long uphill battle. Any newcomer would need an aggressive test suite which covered EVERY known implementation bug. And a sane API. And a project with the political savvy to succesfully lobby for its use through all avenues.
  - argc 13y ago
    This is true. I would trust it more if a company with a lot of cash backed it (google, apple..) of course, leaving it open source. We don't want anything sneaky going on. They might already make a lot of contributions that I don't know about.
  - midas007 13y ago
    Dead wrong. When lives and money are on the line, there is obligation somewhere along the line back to the source. Maybe it stops elsewhere, maybe it doesn't. If folks are depending on open source for life-safety or risk the safety of innocent or targeted individuals, there is an obligation at some point to ensure systems are as secure as humanly possible. More importantly, regardless of circumstances, there is a fundamental duty of engineering ethics. [0] They're not just cliche words or some worthless university course, but the implications of how design decisions and construction of something affects the real world. That crappy commit to [project here] might be the difference between someone living and someone dying. [0] https://en.wikipedia.org/wiki/Engineering_ethics https://en.wikipedia.org/wiki/Engineering_ethics
    - ahomescu1 13y ago
      The page you linked to starts with: Engineering ethics is the field of applied ethics and system of moral principles that apply to the practice of engineering. The field examines and sets the obligations by engineers to society, to their clients, and to the profession. I read this to only apply to professional engineering, where engineers do work for money or other forms of payment. I don't think freely-given (or almost freely, such as GPL code) hobbyist code should be held to these standards, for one reason: it's being given for free, with no expectations in return. If the developer expects nothing from you in exchange for the code, you shouldn't expect anything more than getting the code as-is.
      - vfclists 13y ago
        I disagree with this. If the hobbyist knows that the code may be used in a critical environment then the hobbyist should withdraw the code or make it very clear its suitability for some task has not been tested. It is rather like asking someone for directions and the person misleads you on the basis that you are not paying him for directions. Ethics always apply whether you are being paid or not.
        ahomescu1 13y ago
        > If the hobbyist knows that the code may be used in a critical environment then the hobbyist should withdraw the code or make it very clear its suitability for some task has not been tested. It's already made very clear in the license that the code hasn't been tested, and comes with no guarantees. How much clearer than that can it be? Also, you can't really withdraw code from the Internet. Even if you take down the original repository, there may be dozens of forks.
  - dllthomas 13y ago
    "The problem IMHO is that OpenSSL was used for highly sensitive commercial uses (like Gmail, Amazon and others)" I think it's worth noting that uses can be highly sensitive without being commercial (or governmental). Not that this takes away from your point, which I agree with in broad strokes - responsibility lies first with those deploying; they are the only ones that have access to the full picture.
- randomfool 13y ago
  Where is the best place to donate to improve these critical core-infrastructure pieces? What do I need to do to get people into position to clean up TLS?
  - userbinator 13y ago
    As this is open-source software, the best thing you can donate is your time: If you know even just a little C, download the source and start reading through it. Heartbleed is somewhat more subtle, but you don't need to be much of an expert to catch things like the "goto fail;" bug. The more eyes looking at the code, the better.
- tomphoolery 13y ago
  I'm not sure the "community as a whole was happy" about trusting such critical features to OpenSSL. Were there any other FLOSS solutions that did everything OpenSSL does when a lot of this stuff was developed?
  - cynicalkane 13y ago
    Revealed preferences. People complained about OpenSSL, but in practice were far more concerned with the latest Java ORM or NoSQL database.
    - lmm 13y ago
      The revealed preference is that the industry doesn't really care about security. We follow "industry best practice" - that is, we do the minimum to stop users complaining - but users don't buy based on security, and so it's not worth putting marginal effort into.
- midas007 13y ago
  Double-underscore the last point. TLS WG is the first fail. Look at how many draft feature proposals there are. https://tools.ietf.org/wg/tls/ https://tools.ietf.org/wg/tls/ Where are the proposals for deprecations for killing off features?
- fijal 13y ago
  I guess you can but for some reason very few people do. Look at e.g. number of times browsers have security problems. Are those teams made out of idiots or is it genuinely hard?
- Confusion 13y ago
  Yes, and 'most people' are distracting us from discussing the future: how can a refactoring of the OpenSSL codebase, aimed to improve understandability (which implies improved security) be organized? There will need to be many rounds of small incremental improvements. Who could propose these steps? Who can lead the process, how could contributions be vetted? This is a huge challenge, but unless people start thinking about it and proposals are made, it just won't happen and nothing will change. Just thinking about setting up such a projects boggles the mind, which would like nothing better than to go back to bikeshedding.
x0x0 13y ago
and, ideally, a rigorous test suite; for something that is essentially implementing nested state machines, that probably involves an adversarial state machine aware tester (ie get to state 1; attempt to break; get to state 2, attempt to break, etc), a fuzzer, and a serious unit test suite I get that part of this is a community problem, etc, but a lack of the above on a security product is amazing
- deleted 13y ago
  [deleted]

cynicalkane 13y ago

It's possible to defensively code in C, particularly with modern tooling (some of which lets you write provably secure code) and good process. The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Like most people, I see Heartbleed as a process failure; unlike most people, I think the process failure goes far beyond TLS or OpenSSL or C.

ahomescu1 13y ago
> The fact of the matter is the OpenSSL people simply did not care about writing good code, and the open source community as a whole was happy to assign their most critical security features to a library widely known to be confusing and terrible and not even remotely properly analyzed or tested. Sure, but open source developers have no obligation whatsoever to anyone. Considering they're not being paid in any way for their code, they can write whatever code they want and under whatever process they like. The problem IMHO is that OpenSSL was used for highly sensitive commercial uses (like Gmail, Amazon and others); I think responsibility should fall on companies who used the library without checking it first (Disclaimer: I'm not in anyway associated with OpenSSL or any crypto library, this is just how I see things).
- userbinator 13y ago
  > I think responsibility should fall on companies who used the library without checking it first Agreed. The OpenSSL license (as do many others), has this very clear (if somewhat hard-to-read) disclaimer in it: "IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
  - cynicalkane 13y ago
    This is a standard disclaimer in software. It's just there so you can't sue. It doesn't mean OpenSSL was not intended to be a security library for everyone to use, because it obviously was. I don't like the 'amateur defense' of open source. No, people are not legally liable for code; no, no open-source dev has any obligation to write good code; but OpenSSL is still garbage. As long as you're writing code and using other peoples' code, you might as well care about craftsmanship. If you don't care about craftsmanship, maybe this is the wrong approach to a critical security library.
    - RyanZAG 13y ago
      > but OpenSSL is still garbage. What? Come on. Get a grip on reality. The code is some of the most efficient and widely used. I think it's also the only code that implements the entire spec. It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one.
      - sillysaurus3 13y ago
        It's like those commenting "that skyscraper is garbage" by someone who doesn't even know what you'd need to build a skyscraper, let alone actually tried to build one. It's nothing like that at all. A piece of code's popularity is no evidence of its quality. Otherwise we'd never have advanced beyond BASIC. Implementing an entire spec is nothing to be proud of. Specs are often over-engineered. This is almost certainly the case for TLS. It's 103 pages long: http://tools.ietf.org/html/rfc5246 http://tools.ietf.org/html/rfc5246 We should be questioning the foundations we've been relying on until now when a single vulnerability was able to compromise most of the internet, possibly since 2011.
      - bostik 13y ago
        > The code is some of the most efficient and widely used. Efficient, yes. Throughput in general is not a problem. Widely used, well... yes to that too. Although in this regard I would attributed a good chunk of it to inertia. When (common) use of cryptography started to take off around the time of the browser wars, there weren't too many options around. Web servers needed a way to serve protected content, and there was OpenSSL. Not just available, but already supported by language bindings and relatively easy to set up thanks to mod_ssl. First mover advantage + network effects + the fact that getting crypto right is really hard. If you wanted to unseat OpenSSL, you would need to overcome the fact that despite all the bad rap and the butt-ugly, and the leaky API, it was still getting the most exposure and field testing. Unlike some newcomer library, OpenSSL has the advantage that it is firmly embedded in the software ecosystem, and it has benefited from more than a decade of bugfixes. (I still remember when the timing attack for extracting RSA keys was discovered. The bug was pretty much everywhere, and not just in OpenSSL.) The widespread use of the library boils down to a simple and womewhat depressing fact: OpenSSL is used everywhere because OpenSSL is used everywhere. Replacing it with something better will be a long uphill battle. Any newcomer would need an aggressive test suite which covered EVERY known implementation bug. And a sane API. And a project with the political savvy to succesfully lobby for its use through all avenues.
- argc 13y ago
  This is true. I would trust it more if a company with a lot of cash backed it (google, apple..) of course, leaving it open source. We don't want anything sneaky going on. They might already make a lot of contributions that I don't know about.
- midas007 13y ago
  Dead wrong. When lives and money are on the line, there is obligation somewhere along the line back to the source. Maybe it stops elsewhere, maybe it doesn't. If folks are depending on open source for life-safety or risk the safety of innocent or targeted individuals, there is an obligation at some point to ensure systems are as secure as humanly possible. More importantly, regardless of circumstances, there is a fundamental duty of engineering ethics. [0] They're not just cliche words or some worthless university course, but the implications of how design decisions and construction of something affects the real world. That crappy commit to [project here] might be the difference between someone living and someone dying. [0] https://en.wikipedia.org/wiki/Engineering_ethics https://en.wikipedia.org/wiki/Engineering_ethics
  - ahomescu1 13y ago
    The page you linked to starts with: Engineering ethics is the field of applied ethics and system of moral principles that apply to the practice of engineering. The field examines and sets the obligations by engineers to society, to their clients, and to the profession. I read this to only apply to professional engineering, where engineers do work for money or other forms of payment. I don't think freely-given (or almost freely, such as GPL code) hobbyist code should be held to these standards, for one reason: it's being given for free, with no expectations in return. If the developer expects nothing from you in exchange for the code, you shouldn't expect anything more than getting the code as-is.
    - vfclists 13y ago
      I disagree with this. If the hobbyist knows that the code may be used in a critical environment then the hobbyist should withdraw the code or make it very clear its suitability for some task has not been tested. It is rather like asking someone for directions and the person misleads you on the basis that you are not paying him for directions. Ethics always apply whether you are being paid or not.
      - ahomescu1 13y ago
        > If the hobbyist knows that the code may be used in a critical environment then the hobbyist should withdraw the code or make it very clear its suitability for some task has not been tested. It's already made very clear in the license that the code hasn't been tested, and comes with no guarantees. How much clearer than that can it be? Also, you can't really withdraw code from the Internet. Even if you take down the original repository, there may be dozens of forks.
- dllthomas 13y ago
  "The problem IMHO is that OpenSSL was used for highly sensitive commercial uses (like Gmail, Amazon and others)" I think it's worth noting that uses can be highly sensitive without being commercial (or governmental). Not that this takes away from your point, which I agree with in broad strokes - responsibility lies first with those deploying; they are the only ones that have access to the full picture.
randomfool 13y ago
Where is the best place to donate to improve these critical core-infrastructure pieces? What do I need to do to get people into position to clean up TLS?
- userbinator 13y ago
  As this is open-source software, the best thing you can donate is your time: If you know even just a little C, download the source and start reading through it. Heartbleed is somewhat more subtle, but you don't need to be much of an expert to catch things like the "goto fail;" bug. The more eyes looking at the code, the better.
tomphoolery 13y ago
I'm not sure the "community as a whole was happy" about trusting such critical features to OpenSSL. Were there any other FLOSS solutions that did everything OpenSSL does when a lot of this stuff was developed?
- cynicalkane 13y ago
  Revealed preferences. People complained about OpenSSL, but in practice were far more concerned with the latest Java ORM or NoSQL database.
  - lmm 13y ago
    The revealed preference is that the industry doesn't really care about security. We follow "industry best practice" - that is, we do the minimum to stop users complaining - but users don't buy based on security, and so it's not worth putting marginal effort into.
midas007 13y ago
Double-underscore the last point. TLS WG is the first fail. Look at how many draft feature proposals there are. https://tools.ietf.org/wg/tls/ https://tools.ietf.org/wg/tls/ Where are the proposals for deprecations for killing off features?
fijal 13y ago
I guess you can but for some reason very few people do. Look at e.g. number of times browsers have security problems. Are those teams made out of idiots or is it genuinely hard?
Confusion 13y ago
Yes, and 'most people' are distracting us from discussing the future: how can a refactoring of the OpenSSL codebase, aimed to improve understandability (which implies improved security) be organized? There will need to be many rounds of small incremental improvements. Who could propose these steps? Who can lead the process, how could contributions be vetted? This is a huge challenge, but unless people start thinking about it and proposals are made, it just won't happen and nothing will change. Just thinking about setting up such a projects boggles the mind, which would like nothing better than to go back to bikeshedding.

x0x0 13y ago

and, ideally, a rigorous test suite; for something that is essentially implementing nested state machines, that probably involves an adversarial state machine aware tester (ie get to state 1; attempt to break; get to state 2, attempt to break, etc), a fuzzer, and a serious unit test suite I get that part of this is a community problem, etc, but a lack of the above on a security product is amazing

deleted 13y ago
[deleted]