Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Tue, Aug 3, 2010 at 5:11 PM, Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote: > On Aug 3, 2010, at 4:31 PM, Jarod Wilson wrote: >> >> Yeah, that would be what the http auth-digest part is for. So am I to >> understand correctly that your main opposition to this approach is >> that the auth happens *after* the encryption channel is established, >> rather than being a requirement to bring up the encryption channel? > > Correct. ?The encryption channel does nothing to prevent an attack against auth-digest. ?All it does is prevent eavesdroppers from listening in and seeing your login/password pair. Okay, but I'm pretty sure this is still better than having no auth and no encryption, despite your earlier insistence that it provides "no protection to your server. None. Zilch. Nada." >> So am I to presume you never use online banking and never shop online then? > > Orthogonal issue, or straw-man, take your pick. Maybe. But really, if you don't trust ssl for something like access to mythweb, why on earth would you trust it for accessing your financial information? > Two-tier presences put a firewall between the front-end web server and the back-end application. ?Three-tier presences put firewalls between the front-end web server, the application server, and the back-end database. ?In both cases the firewalls only permit outbound connections; they block all inbound connections. ?This ensures that when -- not if, when -- the public-facing servers are compromised they are still isolated from the internal network and cannot be used to launch further attacks inbound. Regardless of multi-tiered presences, the edge systems can still be used to launch outbound attacks, which I thought you yourself said earlier in this thread was what made a system critical. > On the other hand, it seems that you have no walls between your MythTV web server and everything on your internal network. ?Someone gets past auth-digest somehow and he has full access to everything on the inside. > > Food for thought. If someone gets past auth-digest, they can use mythweb to delete my recordings, they don't have "full access to everything on the inside" (yet). Then I'm in the exact same situation as David. All that happened to him, so far as he's said, is he lost some recordings. They still have to do more work to get access to the system itself beyond just a web ui that lets them delete video files and schedule new recordings, delete channel info, etc. Sure, its possible there's an exploit in the mythweb code they could use to get further access, but the same can be said for a LOT of stuff running on a LOT of web servers all over the place. Connecting anything to a public network is a risk. Period. I know this. Hell, faulty network interface drivers or IP routing stacks can even be exploited to gain system access, even if you have no services publicly exposed. The only way to win the game is not to play. ;) -- Jarod Wilson jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |