Re: [fw-wiz] HTTPS, proxies, and remote developers.
From: Paul Robertson (proberts_at_patriot.net)
Date: 06/16/03
- Previous message: simonis_at_att.net: "Re: [fw-wiz] HTTPS, proxies, and remote developers."
- In reply to: Devdas Bhagat: "[fw-wiz] HTTPS, proxies, and remote developers."
- Next in thread: Eugene Kuznetsov: "RE: [fw-wiz] HTTPS, proxies, and remote developers."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Firewall-Wizards <firewall-wizards@honor.icsalabs.com> Date: Sun, 15 Jun 2003 23:18:51 -0400 (EDT)
On Sat, 14 Jun 2003, Devdas Bhagat wrote:
> I recently setup a mailserver for a software development company. The
> server has a web interface through usermin for password changing and
> handling GPG keys, running on a high port.
I'm assuming that GPG is on the server, and that the participants have the
option of GPG/PGP to the server, ruather than simply mail via the Web
server itself. If so, perhaps a scheme that allows automated password
change requests/authentication via GPG is the way to go?
You could even provide a server-only key for adding new users.
> This company has software developers located at their client locations,
> in different countries.
> The clients have proxies that block access to https, nor will they
> permit ssh/VPNs from their network to the development company by the
> offsite employees.
> The company has asked about the option of moving this to HTTP, but I have
> advised against it (given that GPG keys *may* be exposed on the
> Internet). If the company insists, I will move them to HTTP, with a
> written warning of the risk they are accepting.
The risk on the Internet at large is fairly small. The place they'd be
taking the real risk is out at the end where the Web server lives, and out
at the ends where their respective companies live. I'd put the company
side stuff higher on the list than anywhere else, and likely that's the
same place where the risk of bad actors doing bad things that subvert the
stuff prior to encryption happening is high. Net, that pretty much means
that I would do as you suggest, and document it (perhaps even
auto-footering mails from the server with some link) but not worry overly
much about it. Sniffing really doesn't happen on backbones, so it's the
end nodes where things are sticky, and if they're owned, then it's
probably game over anyway...
> > I do not like the idea of unencrypted communication flowing over the
> Internet for sensitive information. The company IT manager agrees with
> me. The remote client does not like the idea.
> What would be the easiest way to handle this situation? How would you
> resolve a policy issue if one of your clients requires that you use
> unencrypted traffic outbound from their network into yours.
> (Their need to know for traffic on their network against your need for
> security).
Personally, I'd build a seperate infrastructure for links to that company
and firewall the heck out of it. Then I'd let them take all the risk they
wanted to, since I'd only let them at seperated mirrors of my stuff, and
then with anything sensative (to me) not mirrored.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts@patriot.net which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Previous message: simonis_at_att.net: "Re: [fw-wiz] HTTPS, proxies, and remote developers."
- In reply to: Devdas Bhagat: "[fw-wiz] HTTPS, proxies, and remote developers."
- Next in thread: Eugene Kuznetsov: "RE: [fw-wiz] HTTPS, proxies, and remote developers."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
