Re: [HACKERS] Query cancel and OOB data
От | dg@illustra.com (David Gould) |
---|---|
Тема | Re: [HACKERS] Query cancel and OOB data |
Дата | |
Msg-id | 9805310844.AA26816@hawk.illustra.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Query cancel and OOB data ("Matthew N. Dodd" <winter@jurai.net>) |
Список | pgsql-hackers |
Matthew N. Dodd writes: > I think everyone is thinking too hard on this issue. > > Transport security should be just that. > > Use SSL or Kerberos encryption if you wish thoe entire session to be (more > or less) unsnoopable/unspoofable. > > Trying to hack things in will only result in an incomplete and/or ugly > solution. > > The way I see it people have several choices: > > - Run with no network listeners and therefore no network clients to expose > to snooping/spoofing attacks. > > - Require SSLed or Kerberized connections, incuring longer startup times > but insuring a secure channel. > > - Use SKIP or some other IP level encryption system to provide a secure > 'virtual lan' insuring a secure channel. > > - Isolate communication across secure, private networks insuring a secure > channel. > > So long as we make people aware of the risks they are exposing themselves > to, adding 'security features' in places better left to lower level > protocols is unnecessary. Right on. I have been following this discussion about securing the cancel channel hoping for it to come back to earth and now it has. All the major systems I am familiar with (Sybase, Informix, Illustra, MS SQL Server) use TCP as their primary client/server transport and do not use encryption (most even send cleartext passwords over the wire). Some of these systems support only TCP. The assumption is that the dbms and clients are on a private network and not exposed to the internet at large except through gateways of some kind. As I have not heard any horror stories about breakins, denial of service etc at customer sites in my ten years working with this stuff, I assume that while it may happen, it does not happen often enough for the customers to complain to their db vendors about. The other thing is that security is hard. It is hard to make a system secure, and it is even harder to make it usable after you make it secure. And if you don't make it usable, then you find the office and dumpsters filled with post-its with passwords on them. Likewise, most environments are not really secure anyway, it will usually be easier to hack a root shell and kill the postmaster or copy out the data base files than to fool around figuring out the postgres on the wire traffic. -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software 300 Lakeside Drive Oakland, CA 94612 - A child of five could understand this! Fetch me a child of five.
В списке pgsql-hackers по дате отправления: