Re: 7.3.1 stamped
От | Marc G. Fournier |
---|---|
Тема | Re: 7.3.1 stamped |
Дата | |
Msg-id | 20021218223312.C63985-100000@hub.org обсуждение исходный текст |
Ответ на | Re: 7.3.1 stamped (Nathan Mueller <nmueller@cs.wisc.edu>) |
Ответы |
Re: 7.3.1 stamped
|
Список | pgsql-hackers |
On Wed, 18 Dec 2002, Nathan Mueller wrote: > > At this point, all the SSL2 problems are conjecture on my part, which > > I > > don't understand. I hesitate to do anything until someone really > > knowledgeable can comment. Re-enabling SSL2 as part of 7.3.1 makes > > sense until we can get a definative answer on the risks involved. > > I'm not an expert, but as far as I know the only real differences > between SSLv2 and v3 (which isn't different from TLSv1 from a security > standpoint) are some things to prevent some man in the middle attacks. > > Thing is, most man in the middle attacks aren't that advanced. The > attacker will intercept your attempt to connect to the server, do > a handshake with you, do a handshake with the server and just sit > in between. The only way (that I know of) to defend against this > is to use certified public keys and I don't know of a way to do > that with postgres. > > In short, I wouldn't call SSLv2 insecure, just less secure then v3. I > think it's perfectly reasonable to phase it out, just not right now. > It'd be nice to have some sort of transition version so you wouldn't > have to switch over all your different client programs at the same time > you switch all the servers. My preference would be for backwords > compatibility in 7.3 and then eliminate it or provide a compile time > option in 7.4. If the client stays with TLSv1 newer clients will only > use the more secure protocols and older clients will still have the same > problems they did before. I don't think that's too much of a problem. Actually, would be nice if someone submit'd a patch that make choosing which method a configure option :) If nobody else does it, I'll try after I get back from my folks after the holidays ...
В списке pgsql-hackers по дате отправления: