[lug] How do you keep your passwords safe while Paying bills and Day Trading at Work?

[karl horlen]

your example makes me think!

in terms of ISPs.  either the one you connect to from home and or the one you colocate a server with on the backend, would this man in the middle attack be easily applicable to other services like ssh, vpn, etc?

since you have to connect to the internet via your isp.  and since your internet server (if you have one) likely lives behind an isp firewall or router at a facility, it seems likely that (if the isps were willing to spend the time and effort and were dishonest) they could easily setup a proxy to intercept any of these known services to sniff an id / password combo or key long enough, maybe one attempt to get the necessary credentials.  After which they take down the intercept and now have access to a variety of your remote accounts.

does that sound plausible?  

it seems the isps are really functioning as your corporate sys admins in the corporate network example below.  the isps control the in / out pipeline to the greater inet and are always accessed on inbound outbound connections to / from a source destination route.  thus it would seem easy for them to track the controlled traffic and spoof exploits.

am i misguided?  does this seem that easy or is it much more difficult than that? am i really safe doing anything on the internet if i have rogue isps?





it sounds to me like 
> > Am I missing something? My understanding is that as
> long as the machine
> > you are using isn't compromised, and the server
> you are connected to
> > isn't hacked and it is using a certificate signed
> by a legit 3rd party,
> > there is  no need to worry about what's in between
> when using https.
> 
> It's pretty easy, really.
> 
> First, create your own top-level SSL signing certificate. 
> You can name
> it anything you like, including Verisign if you like to be
> sneaky.
> 
> Next, place the public half of this certificate in the
> trusted
> certificate store of all the client systems.
> 
> On the gateway firewall or just before it, place a firewall
> redirect
> rule for HTTPS port 443 to a local intercept proxy.
> 
> Program the proxy to:
>  Receive the HTTPS request
>  Retrieve the actual site certificate and cloning its data
> fields
>  Dynamically generate a SSL certificate for the requested
> site
>  Use the now trusted top-level signing certificate to sign
> the new site
> certificate.
>  Proceed with the man in the middle proxy.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla -
> http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkjr6s0ACgkQolqWs/Y4NLyYkgCgoDIIytsuJ4KgpgKnNbyNDC+u
> ry4An3wYnpSHglXaUeuMGjVznxpTqgst
> =YXcv
> -----END PGP SIGNATURE-----
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List:
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug