Hello,
Iam looking for a way to have an allowed list of SSL enabled sites
that a end user can browse, but this entirely done on a server level
with _zero_ configuration on the pc.
In a dream world, squid would be able to tranparently proxy https and
thus I would create an allowed list of ssl
apache or other reverse proxy.
2009/10/29 Matthew Young myoung24...@gmail.com:
Hello,
Iam looking for a way to have an allowed list of SSL enabled sites
that a end user can browse, but this entirely done on a server level
with _zero_ configuration on the pc.
In a dream world, squid would
Hello,
If I use a reverse proxy I would have to know the SSL key of the
remote SSL site. (gmail.com) so that the reverse proxy server would
decrypt and encrypt. Iam not mistaken.
-- Matt
On Thu, Oct 29, 2009 at 2:50 PM, Bob Beck b...@ualberta.ca wrote:
apache or other reverse proxy.
may be able to do something with relayd, though i'm not sure.
J
On Thu, Oct 29, 2009 at 12:57 PM, Matthew Young myoung24...@gmail.comwrote:
Hello,
If I use a reverse proxy I would have to know the SSL key of the
remote SSL site. (gmail.com) so that the reverse proxy server would
decrypt
Yep. That's why https encrypts the url transmission.
The point is you aren't *supposed* to be able to do that securely.
Your reverse proxy which does this will look like the standard hotel
room sillyness.
2009/10/29 Matthew Young myoung24...@gmail.com:
Hello,
If I use a reverse proxy I would
On Thu, Oct 29, 2009 at 02:57:14PM -0500, Matthew Young wrote:
Hello,
If I use a reverse proxy I would have to know the SSL key of the
remote SSL site. (gmail.com) so that the reverse proxy server would
decrypt and encrypt. Iam not mistaken.
Any decent proxy server accepts the CONNECT
On Thu, Oct 29, 2009 at 3:42 PM, Matthew Young myoung24...@gmail.com wrote:
Iam looking for a way to have an allowed list of SSL enabled sites that a end
user can browse...
Off-topic, but if the users are knowledgeable with OpenSSH, they can
go around any obstacle you place in front of them
THis is great, however out LAN users are all technical. they would
know and the next thing I have is people browsing the internet through
IPs.
It was good, but not applicable here.
On Thu, Oct 29, 2009 at 3:11 PM, Chris Kuethe chris.kue...@gmail.com wrote:
So run your own dns and only resolve
Not unless you know the ip addreses of everything you're hitting. No
amount of magic will make relayd intercept an https session and get
the url out without sending a bogus certificate to the user. If you
have a limited set of places to go, sure, it'll work, but so will just
a plain old pf rule
: Matthew Young myoung24...@gmail.com
To: Bob Beck b...@ualberta.ca; misc@openbsd.org
Sent: Thursday, October 29, 2009 5:57 PM
Subject: Re: PF challenge dealing with HTTPS URL restriction policies..
would it help, other possible solution?
Hello,
If I use a reverse proxy I would have to know
browsing ssl by IP addresses will also result in certificate conflicts
- because the ssl cert is for the name not the IP address.
So if they were willing to do that, they're willing to have your
stupid reverse proxy mitm all your certificates since they'll also
fail.
Perhaps between my extermely
Marcello,
Thank you.. this is good except that I need to configure all my
browsers for downloading the pac file, and some Adware,/antivirus will
not auto discover this.. my users are linux as well as windows sadly.
So while this is a lot more practical then manually configuring
proxies in the
On Thu, Oct 29, 2009 at 1:16 PM, Joachim Schipper
joac...@joachimschipper.nl wrote:
I believe that work is currently underway to make it possible for
multiple SSL-enabled hostnames to share a single IP address, but it will
probably be quite a few years before this is remotely common.
There is
myoung24...@gmail.com
To: misc@openbsd.org
Sent: Thursday, October 29, 2009 7:02 PM
Subject: Re: PF challenge dealing with HTTPS URL restriction policies..
would it help, other possible solution?
Marcello,
Thank you.. this is good except that I need to configure all my
browsers for downloading
14 matches
Mail list logo