Skype breaks too. They also send non-SSL bytes and then SSL.
On Fri, Mar 11, 2011 at 3:17 PM, Jason Haar wrote:
> On 03/12/2011 10:34 AM, Vineet Kumar wrote:
>> BlueCoat's ProxySG is one that runs tranparent SSL protocol detection
>> and breaks if openvpn traffic is coming in via 443. This proxy
On 03/12/2011 10:34 AM, Vineet Kumar wrote:
> BlueCoat's ProxySG is one that runs tranparent SSL protocol detection
> and breaks if openvpn traffic is coming in via 443. This proxy is able
> to pass through other non-HTTP pure SSL traffic though and not just
> HTTPS.
A bit off-topic, but do you kn
BlueCoat's ProxySG is one that runs tranparent SSL protocol detection
and breaks if openvpn traffic is coming in via 443. This proxy is able
to pass through other non-HTTP pure SSL traffic though and not just
HTTPS.
Vineet
On Fri, Mar 11, 2011 at 11:58 AM, Joe Patterson wrote:
> Do you have a poi
Do you have a pointer to a specific SSL proxy that you're talking about?
I have this sneaking suspicion that what you're actually referring to
is a transparent https proxy, which would most definitely *not* work,
as openvpn rides on top of ssl, but not on top of http on top of ssl.
A good test of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 20:09, Vineet Kumar wrote:
> Thanks for your replies.
>
> So,
> - without --tls-auth
> - with tcp as the transport
> if we want to make openvpn purely SSL then are these the complete set
> of things to take care of?:
> 1. Move all P_CONTRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 16:23, Federico Heinz wrote:
> I'm sorry, folks, I'd like to ask for some clarification.
>
> My patch was NAK'd on implementation issues. I offered alternatives
> to them. I got no answer to them.
>
> Should I bother implementing one of t
Thanks for your replies.
So,
- without --tls-auth
- with tcp as the transport
if we want to make openvpn purely SSL then are these the complete set
of things to take care of?:
1. Move all P_CONTROL_* messages to be encapsulated in SSL
2. Stop adding reliability layer over SSL
Let's say, theoretic
I'm sorry, folks, I'd like to ask for some clarification.
My patch was NAK'd on implementation issues. I offered alternatives
to them. I got no answer to them.
Should I bother implementing one of the alternatives, or will the
patch be disregarded nonetheless? If the patch does stand a chance to
b
David Sommerseth wrote:
The reason for this is that OpenVPN is primarily written for the UDP protocol.
~ While SSL itself is very TCP oriented. To my knowledge, there are no UDP
transport support in OpenSSL.
DTLS?
http://sctp.fh-muenster.de/dtls-samples.html
Markus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 10:04, Gert Doering wrote:
| Hi,
|
| On Thu, Mar 10, 2011 at 05:04:48PM -0800, Vineet Kumar wrote:
|> Also, doesn't this make openvpn different from other SSL VPNs which
|> advertise the fact that they are truly SSL?
|
| Well, OpenVPN is "
Hi,
On Thu, Mar 10, 2011 at 05:04:48PM -0800, Vineet Kumar wrote:
> Also, doesn't this make openvpn different from other SSL VPNs which
> advertise the fact that they are truly SSL?
Well, OpenVPN is "truly SSL", but it's not "using https as a browser would
do to hide the fact that there is a VPN
On 03/11/2011 02:04 PM, Vineet Kumar wrote:
> Hi,
> Due to the reliability layer wrapping the SSL handshake packets plus
> a few non-SSL messages during tunnel-setup time the openvpn protocol
> when targeted to port 443 (instead of 1194) ends up breaking if a
> proxy sits in the middle and is exp
Hi,
Due to the reliability layer wrapping the SSL handshake packets plus
a few non-SSL messages during tunnel-setup time the openvpn protocol
when targeted to port 443 (instead of 1194) ends up breaking if a
proxy sits in the middle and is expecting SSL procol on 443. How can I
get around this (w
13 matches
Mail list logo