6 ms·

I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides o

I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.

jerf 10y ago
It's not Rust, but: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C SSL implementations in memory-safe languages exist. Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?
- fredmorcos 10y ago
  (Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
  - omginternets 10y ago
    What are the sacrifices being made by, say, Rust? I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.
    - vvanders 10y ago
      Certain things(circular structures) are harder to represent without dropping down to unsafe code(which is a C equivalent security model). It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.
      - omginternets 10y ago
        Right, so then it is a net advantage over C, with the (negligible) trade-off of compiler-wrangling. The parent comment seemed to suggest the contrary.
  - amenod 10y ago
    I would agree with you if it wasn't for Rust. If you don't know it yet, I would advise you read up about it - it is ideal for replacing C, being equal at speed and better at safety from common programming errors.
    - willtim 10y ago
      There are others too, e.g. ATS
- bluejekyll 10y ago
  > It's not Rust, but: golang This is a false choice. Go and Rust are not replacements for each other. They both have qualities which make each better suited for different environments. Rust is actually capable of replacing all uses of C, Go's runtime will generally be an impediment to using it in certain cases. Also I would argue that there are entire classes of bugs that are still available in Go that are not in Rust, that make it less suited for security. Null pointer exceptions, and unchecked errors are the two that come to mind.
  - brinker 10y ago
    I don't think they were offering up Go as an alternative to C, but rather giving an example of an OpenSSL implementation in a language that isn't C. Rust is mentioned because the prior comment called for the creation of a pure-Rust OpenSSL library as proof that Rust can be used in this context. No such things exists, but they were trying to offer up a similar example to prove the same point.
- kelnos 10y ago
  I don't know if this has changed, but at one point the author of crypto/tls basically said "this hasn't been audited or carefully looked at; do not use this code". Not exactly a ringing endorsement, even if he's stopped saying that.
seanwilson 10y ago
> It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. This reasoning doesn't make sense. Use a language that makes a bunch of security flaws impossible (barring OS and compiler bugs anyway) so that you can concentrate properly on the possible security flaws left. Why deliberately make life hard for yourself if there are other language choices (assuming there are other choices to C in what you're doing)? Even the best developers make mistakes. When you're picking your stack for security sensitive work you should be picking the stack that minimises the chance of mistakes and the impact of those mistakes. C is at high risk of making mistakes and those mistakes have a high chance of being exploitable.
- banachtarski 10y ago
  > Use a language that makes a bunch of security flaws impossible The implicit assumption here is that the language isn't at the same time introducing a number of other vulnerabilities. Is there a language you would like to suggest?
  - chrismonsanto 10y ago
    "Actually, more static analysis makes things less secure" That is a preposterous argument.
    - autognosis 10y ago
      I agree. But who are you talking to? I didn't see that argument made.
    - banachtarski 10y ago
      Come again?
  - seanwilson 10y ago
lawnchair_larry 10y ago
I think the the opposite has been shown. It's not really a complaint, it's a reflection on the facts. C is my favorite language, and a spade is a spade.
ctz 10y ago
I've spent a career of 12 years writing, reviewing and breaking C in high-security products such as HSMs. I'm still to see real world, secure C. Maybe you could point me towards the numerous real world examples of people getting this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote qmail'. (Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of terrible vulnerabilities available to the engineer. This is not defensible these days, in my view.) > So please, pave the road and show us the safer OpenSSL-rust you have. My contribution here is https://github.com/ctz/rustls https://github.com/ctz/rustls
- captn3m0 10y ago
  Off-topic, but a quick question on your project: > Kerberos >broken, obsolete, badly designed, underspecified, dangerous and/or insane Which list does Kerberos fit in?
  - ctz 10y ago
    There are no standard kerberos ciphersuites that use anything better than RC4/IDEA/DES/3DES: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 http://www.iana.org/assignments/tls-parameters/tls-parameter.... So: broken and obsolete.
    - emmelaich 10y ago
      Recent Windows, Linux and Java Kerberos all standardise on AES* and the ones you list are deprecated and for some have to be explicitly enabled. So .. progress is being made.
- astrodust 10y ago
  DJB wrote Qmail, then abandoned it like an unwanted child. He might be a good programmer, but he's a really bad maintainer. OpenSSL was all but abandoned as well. At least now there's a lot of attention being focused on making it better and more maintainable. There's numerous tire fires out there: ImageMagick, OpenSSL, some Linux kernel drivers, and other projects people just take for granted without pitching in to help fix things. Re-writing in Rust is a form of helping, and maybe in the process we'll find bugs in the originals or wholesale replace them with something better.
astrodust 10y ago
It's easy to interpret these arguments as "C sucks, let's use Rust" instead of "C is a very mature language with enormously complicated code-bases in play running mission critical software which is not trivially replaced by something like Rust but which could stand to benefit from building things into the compiler to check for mistakes like the Rust compiler does." Compiling C code is easy, but auditing C code is hard. Getting Rust code to compile without getting berated about every little thing is hard, but at least you're confident then you've got everything right.

jerf 10y ago

It's not Rust, but: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C SSL implementations in memory-safe languages exist. Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?

fredmorcos 10y ago
(Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
- omginternets 10y ago
  What are the sacrifices being made by, say, Rust? I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.
  - vvanders 10y ago
    Certain things(circular structures) are harder to represent without dropping down to unsafe code(which is a C equivalent security model). It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.
    - omginternets 10y ago
      Right, so then it is a net advantage over C, with the (negligible) trade-off of compiler-wrangling. The parent comment seemed to suggest the contrary.
- amenod 10y ago
  I would agree with you if it wasn't for Rust. If you don't know it yet, I would advise you read up about it - it is ideal for replacing C, being equal at speed and better at safety from common programming errors.
  - willtim 10y ago
    There are others too, e.g. ATS
bluejekyll 10y ago
> It's not Rust, but: golang This is a false choice. Go and Rust are not replacements for each other. They both have qualities which make each better suited for different environments. Rust is actually capable of replacing all uses of C, Go's runtime will generally be an impediment to using it in certain cases. Also I would argue that there are entire classes of bugs that are still available in Go that are not in Rust, that make it less suited for security. Null pointer exceptions, and unchecked errors are the two that come to mind.
- brinker 10y ago
  I don't think they were offering up Go as an alternative to C, but rather giving an example of an OpenSSL implementation in a language that isn't C. Rust is mentioned because the prior comment called for the creation of a pure-Rust OpenSSL library as proof that Rust can be used in this context. No such things exists, but they were trying to offer up a similar example to prove the same point.
kelnos 10y ago
I don't know if this has changed, but at one point the author of crypto/tls basically said "this hasn't been audited or carefully looked at; do not use this code". Not exactly a ringing endorsement, even if he's stopped saying that.

seanwilson 10y ago

> It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. This reasoning doesn't make sense. Use a language that makes a bunch of security flaws impossible (barring OS and compiler bugs anyway) so that you can concentrate properly on the possible security flaws left. Why deliberately make life hard for yourself if there are other language choices (assuming there are other choices to C in what you're doing)? Even the best developers make mistakes. When you're picking your stack for security sensitive work you should be picking the stack that minimises the chance of mistakes and the impact of those mistakes. C is at high risk of making mistakes and those mistakes have a high chance of being exploitable.

banachtarski 10y ago
> Use a language that makes a bunch of security flaws impossible The implicit assumption here is that the language isn't at the same time introducing a number of other vulnerabilities. Is there a language you would like to suggest?
- chrismonsanto 10y ago
  "Actually, more static analysis makes things less secure" That is a preposterous argument.
  - autognosis 10y ago
    I agree. But who are you talking to? I didn't see that argument made.
  - banachtarski 10y ago
    Come again?
- seanwilson 10y ago

lawnchair_larry 10y ago

I think the the opposite has been shown. It's not really a complaint, it's a reflection on the facts. C is my favorite language, and a spade is a spade.

ctz 10y ago

I've spent a career of 12 years writing, reviewing and breaking C in high-security products such as HSMs. I'm still to see real world, secure C. Maybe you could point me towards the numerous real world examples of people getting this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote qmail'. (Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of terrible vulnerabilities available to the engineer. This is not defensible these days, in my view.) > So please, pave the road and show us the safer OpenSSL-rust you have. My contribution here is https://github.com/ctz/rustls https://github.com/ctz/rustls

captn3m0 10y ago
Off-topic, but a quick question on your project: > Kerberos >broken, obsolete, badly designed, underspecified, dangerous and/or insane Which list does Kerberos fit in?
- ctz 10y ago
  There are no standard kerberos ciphersuites that use anything better than RC4/IDEA/DES/3DES: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 http://www.iana.org/assignments/tls-parameters/tls-parameter.... So: broken and obsolete.
  - emmelaich 10y ago
    Recent Windows, Linux and Java Kerberos all standardise on AES* and the ones you list are deprecated and for some have to be explicitly enabled. So .. progress is being made.
astrodust 10y ago
DJB wrote Qmail, then abandoned it like an unwanted child. He might be a good programmer, but he's a really bad maintainer. OpenSSL was all but abandoned as well. At least now there's a lot of attention being focused on making it better and more maintainable. There's numerous tire fires out there: ImageMagick, OpenSSL, some Linux kernel drivers, and other projects people just take for granted without pitching in to help fix things. Re-writing in Rust is a form of helping, and maybe in the process we'll find bugs in the originals or wholesale replace them with something better.

astrodust 10y ago

It's easy to interpret these arguments as "C sucks, let's use Rust" instead of "C is a very mature language with enormously complicated code-bases in play running mission critical software which is not trivially replaced by something like Rust but which could stand to benefit from building things into the compiler to check for mistakes like the Rust compiler does." Compiling C code is easy, but auditing C code is hard. Getting Rust code to compile without getting berated about every little thing is hard, but at least you're confident then you've got everything right.