Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow cipher specification for BearSSL #5151

Merged
merged 3 commits into from
Sep 21, 2018

Conversation

earlephilhower
Copy link
Collaborator

BearSSL has many more ciphers than axTLS, but they are more compute intensive
and slower. Add an option to use only the same, limited security, axTLS ciphers
as well as allow users to specify any suite of ciphers they want using standard
BearSSL formats.

Fixes #5110

BearSSL has many more ciphers than axTLS, but they are more compute intensive
and slower.  Add an option to use only the same, limited security, axTLS ciphers
as well as allow users to specify any suite of ciphers they want using standard
BearSSL formats.

Fixes esp8266#5110
For C++ afficionados, allow std::vectors to be passed in to the setCipher()
routine.

The BearSSL object will now keep a copy of any set ciphers and free on object
destruction.  These custom lists should normally only be 1-4 entries long, so it
is not expected to be a memory hog having this extra copy.
@devyte devyte merged commit cc284bb into esp8266:master Sep 21, 2018
@earlephilhower earlephilhower deleted the bssl_ciphers branch September 21, 2018 14:55
@artua
Copy link

artua commented Oct 23, 2018

@earlephilhower Can't use setCipher:

  BearSSL::WiFiClientSecure client;
  client.setCipher();
_'class BearSSL::WiFiClientSecure' has no member named 'setCipher'_

@earlephilhower
Copy link
Collaborator Author

client.setCiphers. Plural. Easy mistake to make.

@artua
Copy link

artua commented Oct 23, 2018

@earlephilhower Yeah.
But not my mistake. :)

af699f4

For C++ afficionados, allow std::vectors to be passed in to the setCipher()
routine.

@marcelstoer
Copy link
Contributor

I'm a bit lost figuring out what your release planning is (apart from the major milestones you track on GitHub). Is there any chance fixes like this one could go into a 2.4.3?

@devyte
Copy link
Collaborator

devyte commented Dec 29, 2018

Hi @marcelstoer
our current release model is linear, not branched. That means there won't be a 2.4.3, and there are no backports of fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants