-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
FAB-18192 Fixed TLS certs validation for consenters. #1888
Conversation
e0dba77
to
22d6046
Compare
ad5d649
to
749bdfa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for picking this task up! A few general comments that stood out on a first pass.
Going to take a deeper look at the more substantial changes in etcdraft/util.go.
3d79ab7
to
f0325f9
Compare
7481ac3
to
5ccc63f
Compare
Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this pull request! It's definitely a bug that we're not validating using the latest config. There are a few points, in particular since we are looking at the full config, and not performing the validation only on the update information, I'm a little concerned about unrelated config updates being rejected because of temporal checks. I've included a comment at the spot, but, I think we could simplify this code by simply skipping the expiration checks. If we are really convinced that they are the right thing to do, then we need to be careful that we only apply them to new certificates in the channel config, and not existing ones. If we apply it to existing ones, then as soon any orderer TLS cert expires, all channel updates would begin failing until the issue is fixed.
if err != nil { | ||
return err | ||
} | ||
|
||
//new config metadata was verified above. Additionally need to check new consenters for certificates expiration | ||
for _, c := range changes.AddedNodes { | ||
if err := validateConsenterTLSCerts(c, verifyOpts, false); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that we should be checking certificate expiration here. For instance, we could have an expired certificate that we want to leave in place while we grow or shrink the consenter set. If we want to check expiration I'd say we need to only check expiration of new certificates.
I'd also note, that the orderer has been modified to perform ID validation not based on cert literals anymore, but rather based on public key, so, in some cases, even if the TLS certificate is expired in the channel config, an orderer with a valid and unexpired TLS certificate with matching public key may successfully be validated using this information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jyellick but slicechanges.AddedNodes
contains only new nodes(only one node actually), doesn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct, sorry for missing this.
…expiration is checked only on new consenters. Improved tests. Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is in good enough shape to merge. I've opened https://jira.hyperledger.org/browse/FAB-18257 to address removing the test fixtures once go v1.15 is being used for Fabric.
@jyellick Can you run the backport command to get this in the release-2.2 branch? Thanks! (I assume only maintainers are allowed to do that based on my previous failed attempts to run it myself) @Mergifyio backport release-2.2 |
@wlahti is not allowed to run commands |
@Mergifyio backport release-2.2 |
* FAB-18192 Fixed TLS certs validation for consenters. Verification of TLS cert against simulated config, not the last one. To achieve that, metadata validator interface was changed, now it requires orderer config instead of just consensus metadata. Also, TLS verification was moved to VerifyMetadata function, it shouldn't have been part of ComputeMembershipChanges. Fixed tests. Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> * fixed consenters tests Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> * modified VerifyConfigMetadata with ignoreCertExpiration option Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> * generation of verifying options based only on simulated config, fixes Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> * fixed consenters map Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> * Removed ignoreCertExpiration option from VerifyConfigMetadata, certs expiration is checked only on new consenters. Improved tests. Signed-off-by: kopaygorodsky <vlad.kopaygorodsky@gmail.com> (cherry picked from commit 886d3cc) # Conflicts: # orderer/common/msgprocessor/systemchannelfilter_test.go # orderer/common/multichannel/chainsupport_test.go # orderer/consensus/etcdraft/consenter.go # orderer/consensus/etcdraft/consenter_test.go # orderer/consensus/etcdraft/util_test.go
Command
|
woohoo, my first PR to fabric is merged :) |
Congratulations, Nice work :)
S Rob Murgai
He / Him / His
Program Director - Hyperledger Fabric
IBM Blockchain
Raleigh-Durham, NC
M: 919.342.8432 | LinkedIn: Rob-Murgai
----- Original message -----From: Vladyslav Kopaihorodskyi <notifications@github.com>To: hyperledger/fabric <fabric@noreply.github.com>Cc: Subscribed <subscribed@noreply.github.com>Subject: [EXTERNAL] Re: [hyperledger/fabric] FAB-18192 Fixed TLS certs validation for consenters. (#1888)Date: Tue, Oct 6, 2020 1:42 PM
woohoo, my first PR to fabric is merged :)
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
* FAB-18192 Fixed TLS certs validation for consenters. Verification of TLS cert against simulated config, not the last one. To achieve that, metadata validator interface was changed, now it requires orderer config instead of just consensus metadata. Also, TLS verification was moved to VerifyMetadata function, it shouldn't have been part of ComputeMembershipChanges. Fixed tests. Signed-off-by: Vladyslav Kopaihorodskyi <vlad.kopaygorodsky@gmail.com>
* FAB-18192 Fixed TLS certs validation for consenters. (#1888) * FAB-18192 Fixed TLS certs validation for consenters. Verification of TLS cert against simulated config, not the last one. To achieve that, metadata validator interface was changed, now it requires orderer config instead of just consensus metadata. Also, TLS verification was moved to VerifyMetadata function, it shouldn't have been part of ComputeMembershipChanges. Fixed tests. Signed-off-by: Vladyslav Kopaihorodskyi <vlad.kopaygorodsky@gmail.com> * IT - update MSP and consenters set in single config update FAB-18192 Signed-off-by: Will Lahti <wtlahti@us.ibm.com> * Fix bug in consenter cert validation logic It was accidentally verifying only the clientCert and not the cert that was passed in. FAB-18269 Signed-off-by: Will Lahti <wtlahti@us.ibm.com> * Update release notes for 2.2.2 for FAB-18192 bug fix Signed-off-by: Will Lahti <wtlahti@us.ibm.com> Co-authored-by: Vladyslav Kopaihorodskyi <vlad.kopaygorodsky@gmail.com>
Hello! Is that the new version with this latest fix already available in Docker Hub? |
There is not yet, you will need to build it yourself, or pull it from |
Hello, @btl5037 , I've pulled here the
Is this bug still persisting with you? |
@lucianoacsilva Can you pull the image again, artifactory was receiving, but not publishing the updates, it's published now. |
@btl5037 , removed the image, pulled it again when starting main network, error still persists:
|
@lucianoacsilva Can you ping me on chat.hyperledger.org, my ID is |
@lucianoacsilva @btl5037 I've built an image from master branch and this fix works. On the other hand, I've tried hyperledger-fabric.jfrog.io/fabric-orderer:amd64-2.2-stable and see this issue. |
I see, @kopaygorodsky . How could I build those images from the master branch? |
@lucassaldanha |
Wait, is that the image of the peer or the orderer? @btl5037 mentioned me the |
orderer validates block, so you need to use orderer image |
Signed-off-by: kopaygorodsky vlad.kopaygorodsky@gmail.com
Type of change
Description
Fixes usecase when you add new org with a consenter.
Verification of consenter's TLS certs against simulated config, not the last one. To achieve that, metadata validator interface was changed, now it requires orderer config instead of just consensus metadata. Also, TLS verification was moved to VerifyConfigMetadata function. Added
ignoreCertExpiration
option to ignore expiration errors when validating config metadata.Additional details
1.
consenter.IsChannelMember
returns an error if metadata has a consenter with an invalid certificate or signed by unknown MSP.2.Added new tests, fixed existing tests.
3.Checked the fix on a test network.
Related issues
https://jira.hyperledger.org/browse/FAB-18192