back to article What do you give a bear that wants to fork SSL? Whatever it wants!

Into a world already crowded with big name alternatives to OpenSSL, an indy project could look like “yet another SSL implementation,” but Vulture South suspects there are good reasons to take a close look at the just-launched BearSSL. One is that its author, Thomas Pornin, has ignored the kinds of legacy protocols that occupy …

  1. Anonymous South African Coward Silver badge

    Excellent idea of throwing out old baggage and starting fresh.

    Old baggage = possible vulnerabilities.

    1. Anonymous Coward
      Anonymous Coward

      Excellent idea of throwing out old baggage and starting fresh.

      Old baggage = possible vulnerabilities.

      Yes and no - the issue is that making that work in the real world is that everything upgrades with it. You could argue that has to happen anyway. but if you've ever done a system wide refresh you know it's not that simple.

      That said, I applaud the effort because it ticks all the "sane" boxes, motivation as well as its approach.

  2. TeeCee Gold badge
    Meh

    Since BearSSL has to be small, Pornin has decided to ignore malloc() and dynamic allocation entirely:

    Well, I suppose that's one reason. The other would be that a large number of well-known vulns are down to developer fuckups with dynamic memory handling.

  3. Dazed and Confused Silver badge

    25KB or RAM

    My laptop has just asked to download a 200MB update to the WiFi driver!

    It's really refreshing to see a coder looking at using sensible amounts of memory for a change rather than working on the principle of Weeeeeeeeeeeeeeeeee memorry's cheap

    1. Lee D Silver badge

      Re: 25KB or RAM

      Most of that 200Mb will be a setup program, .NET frameworks, taskbar utilities, multiple copies of the driver, etc. rather than an actual wifi driver though.

      Same with print drivers. The actual printer driver is only 50Kb or less, which isn't bad when it's doing things like connecting to network printers, interpreting Postscript, offering booklet and folding, etc.

      Bundle it via the HP utils, though, and you're installing 400Mb of junk to get it.

      That said, when I program I'm always shocked by HOW LITTLE my programs take. On disk. In RAM. Even the processor usage. When I read the articles about how GTA V renders, I'm astounded - things like hundreds or thousands of buffers rendering simultaneously at 120fps to show the final image, it's amazing.

      But when I program, I get tiny little compact things which barely approach a couple of meg even if I statically include all the libraries. And then I look in my ProgramFiles folder or my Steam folders and nearly have a heart attack at the sizes in there.

      I get data sizes - they can be huge for things like 3D games. But code sizes? What the hell are we doing to make things this big? And the bigger they are, they more to go wrong and the slower they operate (or are you saying that that code is just never actually executed? Then it's data, get it out of the program).

    2. Doctor Syntax Silver badge

      Re: 25KB or RAM

      And by comparison I've just downloaded a 460kB update of python-imaging which frees 108kB of storage.

      1. Nick Ryan Silver badge
        Joke

        Re: 25KB or RAM

        How do pictures of snakes reduce storage? :)

        1. Anonymous Coward
          Coat

          Re: 25KB or RAM

          How do pictures of snakes reduce storage? :)

          You clearly have never seen how a python enjoys its lunch… it squeezes it.

  4. Milton Silver badge

    "It's been argued repeatedly that 'things' aren't going to get decent security in their own right, because they're small and stupid"

    How quickly and frequently we forget that it's possible to write extremely effective and powerful code to run on small, slow CPUs with little memory or storage access. Arguably, the availability of ever-faster CPUs, vast amounts of RAM and colossal storage over the course of four decades has allowed us to become lazier, dumber coders. I still have memories of writing printer drivers for 6502 chips in assembler (because our printer wasn't supported). I'm not the only one here today who will recall slotting a 20Mb 'smart card' into a year-old 286 based PC to support work in Ada and C++ ... and less than 30 years later my phone has an *accessory* smaller than my pinky nail that will hold six thousand times as much data. The phone itself is, by those standards, an insanely powerful computer.

    In short, I don't believe it's not possible to write solid and secure interfaces for 'small, stupid' devices. In fact, simplicity of devices and of the code to run on them might well be a security asset, as the article itself frequently alludes. KISS rules!

  5. Len Silver badge

    Isn't this the space mbedTLS already operates in? As little legacy nonsense as possible, very small footprint etc. https://tls.mbed.org/

    1. Anonymous Coward
      Anonymous Coward

      mbed TLS requires calloc() and free() for some operations.

      Plus it's good to have an alternative. Both are under very permissive licenses (mbed TLS under Apache/GPL; BearSSL under MIT). I'd say mbed TLS appears to have the upper hand in supporting more algorithms (judging from a quick glance over the documentation) and is more mature, but I do admire BearSSL's minimalist approach.

  6. Destroy All Monsters Silver badge
    Mushroom

    Oh yeah?

    It's been argued repeatedly that “things” aren't going to get decent security in their own right, because they're small and stupid.

    There is a special FEMA trailer for people who argue this kind of stuff.

    Indeed, this just would mean these devices were trying to occupy an economic niche that is not acceptable. Same as a factory that can only exist if it can dump the toxic leftovers into the nearest river.

    Either legislate this away or fix this.

    Since BearSSL has to be small, Pornin has decided to ignore malloc() and dynamic allocation entirely: “the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen()” from the underlying C library, Pornin says.

    Somebody has taken up lessons from the Misra C manual? GOOD!

    1. Mike 16 Silver badge

      Re: Oh yeah?

      I do applaud bringing a little sanity to security libraries, but I couldn't help having a twitch of humorous response to:

      ----

      “the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen()” from the underlying C library, Pornin says.

      Somebody has taken up lessons from the Misra C manual? GOOD!

      ----

      As I mentioned in another comment yesterday, when I wrote a validation suite for, essentially, the functions declared in string.h, I found errors in one vendor's memcmp() and and memmove(), and another's memcpy(). So while I admire the use of the "platonic" functions, I'd suggest that actual implementors "trust, but verify"

      (And if constant time is important, the vendor-supplied implementations should be _very_ carefully verified, since all those errors were caused by mistaken "optimizations", that would have altered run times even if they had gotten the right answer)

      1. Destroy All Monsters Silver badge

        Re: Oh yeah?

        I don't understand the "constant time" thing.

        Shurely you want to have a "done before time x" constraint?

        Constant time is for the simplest "fall-down-from-top-to-bottom" algorithms or for the magic world of mathematics.

        1. Charles 9 Silver badge

          Re: Oh yeah?

          You want constant time (as in each iteration takes the same amount of time regardless of the input) because you have to consider side channel attacks. For example, if you get a hint that one input takes more or less time than another input, then you can file that datum as a hint on your original input. Side channel attacks can be done in all sorts of physical ways: measuring current draw, CPU temperature, times, etc. It's sorta like reconstructing a crashed airliner: a piece here, a piece there, but you eventually get enough together to get an idea of what happened. Same here.

          So, no, you don't want a "done before time x" constraint. You want (and need) a "done IN time x" constraint or you'll be giving away hints.

  7. Dan 55 Silver badge
    Stop

    Didn't the IETF bloke just say stop making up new protocols to do the same thing? Same goes for libraries. There is already LibreSSL and BoringSSL that could probably be improved as well as commercial solutions like ARM's.

    1. Anonymous Coward
      Anonymous Coward

      There's no change in protocol. These are simply different software stacks to port data from A to B in a manner that complies with an established standard..

      1. Dan 55 Silver badge

        I mean the same advice for protocols applies to libraries.

        1. Mike 125

          >>Didn't the IETF bloke just say stop making up new protocols to do the same thing? Same goes for libraries.

          No. The protocol is the abstract behaviour e.g.

          RFC: 793 TRANSMISSION CONTROL PROTOCOL

          Only one of those is required (plus multiple revisions!).

          The 'library' is the implementation. And there can can be thousands of those, depending on detailed platform requirements.

          Unfortunately, in the security sphere, both the protocol and the implementation matter, which is why it's hard.

          1. Dan 55 Silver badge

            Yes, which is what I thought I was suggesting - instead of wasting effort making a new library when there are already a few around, put that effort into improving an existing one.

            I'm obviously not very good with words today. Must be something in the news affecting me.

            1. Anonymous Coward
              Anonymous Coward

              The thing is that BearSSL is operating on a very different design philosophy: one that means the existing libraries may not be "fit for the purpose". If nothing's fit for the purpose, your only option is to roll your own.

  8. JimmyPage Silver badge
    Thumb Up

    20K+ 25K

    So it could have run in a 48K spectrum ?

    Kewl :)

    1. Lee D Silver badge

      Re: 20K+ 25K

      Sure.

      If you feel like waiting an hour for the first connection to a secure webpage (even if you could network the ZX Spectrum somehow to Ethernet - they only ever had the ZX Net thing that was rare and used only in schools).

      1. phuzz Silver badge

        Re: 20K+ 25K

        Ok, so not on a speccy, but how about an Amiga?

        1. Sandtitz Silver badge

          Re: 20K+ 25K

          "Ok, so not on a speccy, but how about an Amiga?"

          OpenSSL has been ported to Amiga and this BearSSL is supposedly lighter on resources so why not?

          1. Charles 9 Silver badge

            Re: 20K+ 25K

            Lighter on resources, maybe, but what about computational power. A 68000 is a far cry from say a modern ARMv7.

      2. William Towle
        Boffin

        Re: 20K+ 25K

        T'old Speccy's screen RAM being around 6.75K is enough to rule out having enough space on its own, although maybe something is possible once you've got the bank switching of the 128K models.

        *starts wondering idly about some of the Unix clones for Z80*

  9. This post has been deleted by its author

  10. Chewi

    Interesting choice of name

    Given that one of its main rivals will be the project formerly known as PolarSSL.

    1. raesene

      Re: Interesting choice of name

      Thomas has a history of naming things with ursine related names, e.g. the Makwa hashing algorithm http://www.bolet.org/makwa/

  11. Anonymous Coward
    Anonymous Coward

    Irony, false advertising, or backward name compatibility?

    After all, why name it BearSSL if it contains no SSL at all?

    More seriously, why include TLS 1.0, since it's already considered insecure and forbidden by, eg PCI-DSS? Isn't that already old baggage that's kept in?

    1. Anonymous Coward
      Anonymous Coward

      Re: Irony, false advertising, or backward name compatibility?

      Probably because later versions of TLS basically use the same techniques as 1.0, only in more secure ways. Difference in degree instead of kind the way SSL is different. IOW, the code's already there to cover 1.1 and up, might as well support 1.0 but put it bottom of the list.

      1. DougS Silver badge

        Re: Irony, false advertising, or backward name compatibility?

        The PCI requirement for TLS 1.1 was pushed back to June 2018.

        1. Alistair Silver badge
          Coat

          Re: Irony, false advertising, or backward name compatibility?

          @DougS - beat me to it.

          Although we've already met auditors that were not aware of that either.

    2. raesene

      Re: Irony, false advertising, or backward name compatibility?

      AFAIK, the reason for the name is that SSL is more generally recognised than TLS as a term

    3. Vincent Ballard

      Re: Irony, false advertising, or backward name compatibility?

      You have to support TLS 1.0 if you want to allow connections from IE10 or from Android <= 4.3.

  12. This post has been deleted by its author

  13. chasil

    TLS 1.3

    It would make more sense, to support *ONLY* (draft) TLS 1.3 if minimal footprint is required.

    TLS 1.3 will only allow two symmetric ciphers (initially), and they must be AEAD. The selected ciphers are AES-GCM, and ChaCha20-Poly1305. All the older ciphers are gone.

    Limited support for TLS 1-1.2 might be acceptable, but only with the allowed TLS 1.3 AEAD set.

    Do we really need to keep dragging SHA1 into new systems?

    1. Anonymous Coward
      Anonymous Coward

      Re: TLS 1.3

      "Do we really need to keep dragging SHA1 into new systems?"

      As long as old but irreplaceable systems exist that can't grok TLS > 1.0, yes.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019