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

Gobby seems to silently accept expired certificates #61

Closed
pkern opened this issue May 6, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@pkern
Copy link
Contributor

commented May 6, 2015

Debian bug #783601 reported that gobby silently accepts expired certificates. The mentioned site has since been fixed and I'm unsure if that'd be due to pinning or if there's a genuine validation error. (But then the function in libinfinity doesn't seem to tolerate expiry not even with pinning AFAICS.) The report in full:

At the moment the certificate of gobby.debian.net is expired (reported
separately as Bug#783599) but Jessie's gobby happily establishes a full
connection to it without any warning. This is a regression since Wheezy,
since it's not the case in gobby-0.5 (version 0.4.94-5), which shows a
warning stating that the certificate has expired with the option to
accept it any way.

It's strange (and perhaps relevant), but if one configures an empty file
as the "Trusted CAs" file in Jessie's gobby's security options, then
it lists the connection with a "certificate expired" error next to it in
the Document Browser pane. However, no prompt is shown, so it's not
possible to manually accept the expired certificate.

@aburgm

This comment has been minimized.

Copy link
Contributor

commented May 7, 2015

Right, so the expected result is a straight rejection of the certificate, without allowing the user to accept it anyway. I changed this between 0.4.94 and 0.5.0.

I'll see if I can reproduce this, but we should definitely also add some unit tests for certificate verification...

@aburgm

This comment has been minimized.

Copy link
Contributor

commented May 12, 2015

This is fixed in libinfinity, in the master and libinfinity-0.6 branches. I also added a unit test for this case and hope to add more certificate validation tests later. I plan to make a libinfinity-0.6 bugfix release tomorrow.

@aburgm aburgm closed this May 12, 2015

@DimStar77

This comment has been minimized.

Copy link

commented Jun 2, 2015

Does this also apply to the 0.5.x branch of libinfinity? From what I see, the code is rather different there.

@aburgm

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2015

No, this does not apply to 0.5.x. The code was indeed changed between 0.5 and 0.6, to make certificate pinning more SSH-like. For example, if a host has a self-signed certificate, with 0.5.x you would be asked at every connection attempt whether to actually connect, while with 0.6.x you are only asked the first time as long as that host shows you the same certificate every time. The bug was introduced as a result of this change.

By the way, libinfinity master has now also certificate validation tests for several other cases of valid or invalid certificates, not only expiration. So I hope this does not happen again next time the validation code is refactored :)

@pkern

This comment has been minimized.

Copy link
Contributor Author

commented Jun 14, 2015

For reference: This has been assigned CVE-2015-3886.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.