Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
От | Robert Haas |
---|---|
Тема | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 |
Дата | |
Msg-id | CA+TgmobTz6cftKYsg2xMdFsC=PxGFysbvd06s=NedgMUV8E82w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
|
Список | pgsql-jdbc |
On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost <sfrost@snowman.net> wrote: > I certainly wouldn't object to someone working on this, but I feel like > it's a good deal more work than perhaps you're realizing (and I tend to > think trying to use the Windows SSL implementation would increase the > level of effort, not minimize it). I agree that it's a fair amount of work, but if nobody does it, then I think it's pretty speculative to suppose that the feature actually works correctly. > Perhaps it wouldn't be too bad to > write a one-off piece of code which just connects and then returns the > channel binding information on each side and then one could hand-check > that what's returned matches what it's supposed to based on the RFC, but > if it doesn't, then what? Then something's broken and we need to fix it before we start committing patches. > In the specific case we're talking about, > there's two approaches in the RFC and it seems like we should support > both because at least our current JDBC implementation only works with > one, and ideally we can allow for that to be extended to other methods, > but I wouldn't want to implement a method that only works on Windows SSL > because that implementation, for whatever reason, doesn't follow either > of the methods available in the RFC. I am very skeptical that if two people on two different SSL interpretations both do something that appears to comply with the RFC, we can just assume those two people will get the same answer. In an ideal world, that would definitely work, but in the real world, I think it needs to be tested or you don't really know. I agree that if a given SSL implementation is such that it can't support either of the possible channel binding methods, then that's not our problem; people using that SSL implementation just can't get channel binding, and if they don't like that they can switch SSL implementations. But I also think that if two SSL implementations both claim to support what's needed to make channel binding work and we don't do any testing that they actually interoperate, then I don't think we can really know that we've got it right. Another way of validating Michael's problem which I would find satisfactory is to go look at some other OpenSSL-based implementations of channel binding. If in each case they are using the same functions that Michael used in the same way, then that's good evidence that his implementation is doing the right thing, especially if any of those implementations also support other SSL implementations and have verified that the OpenSSL mechanism does in fact interoperate. I don't really know why we're arguing about this. It seems blindingly obvious to me that we can't just take it on faith that the functions Michael identified for this purpose are the right ones and will work perfectly in complete compliance with the RFC. We are in general very reluctant to make such assumptions and if we were going to start, changes that affect wire protocol compatibility wouldn't be my first choice. Is it really all that revolutionary or controversial to suggest that this patch has not yet had enough validation to really know that it does what we want? To me, it seems like verifying that a patch which supposedly implements a standard interoperates with something other than itself is so obvious that it should barely need to be mentioned, let alone become a bone of contention. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Следующее
От: Álvaro Hernández TortosaДата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256