On 03/04/2015 22:12, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Salz, Rich
Sent: Friday, April 03, 2015 15:55
To: openssl-users@openssl.org
Subject: Re: [openssl-users] HTTP / HTTPS on same port
It is a hack.
That's debatable. What
((szData[3] == 0 && szData[4] < 5)
|| (szData[9] == szData[1])))
{
// SSLv3
nRet = 1;
}
}
}
return nRet;
}
On Sat, Apr 4, 2015 at 5:10 AM, James Cloos wrote:
> >>>>> "JR" == Joris Van Remoorte
>>>>> "JR" == Joris Van Remoortere writes:
JR> I would like to ask your opinion and advice on accepting HTTP / HTTPS
JR> connections on the same port.
IPP support both w/ and w/o tls on port 631.
Cups handles it like this:
http://www.pwg.org/archives/ipp/20
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich
> Sent: Friday, April 03, 2015 15:55
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] HTTP / HTTPS on same port
>
> It is a hack.
That's debatable. What's so
On 03/04/15 20:48, Joris Van Remoortere wrote:
> Hello,
>
> I would like to ask your opinion and advice on accepting HTTP / HTTPS
> connections on the same port.
>
> I currently have a prototype that peeks at the first byte after
> accepting a new connection, and dispatch
It is a hack. Most people do it the other way and look for a G or P as the
first letter.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Hello,
I would like to ask your opinion and advice on accepting HTTP / HTTPS
connections on the same port.
I currently have a prototype that peeks at the first byte after accepting a
new connection, and dispatches to the appropriate routines based on whether
the first byte is 0x16 or not. This
Carlos Vicente <[EMAIL PROTECTED]> writes:
> Thanks again.
> Another question:
> Why woudn't a browser complain about a certificate with "*" as CN?
> Aren't they supposed to compare the CN with the server's name?
* is a wildcard.
-Ekr
--
[Eric Rescorla [EMAIL
Thanks again.
Another question:
Why woudn't a browser complain about a certificate with "*" as CN?
Aren't they supposed to compare the CN with the server's name?
Eric Rescorla wrote:
>There are two main approaches:
>1. Use the CONNECT method, as you suggest. You tell the browser that
>it is to
I'm resending this because I've been having mailer problems.
Sorry if you get it twice.
Carlos Vicente <[EMAIL PROTECTED]> writes:
> Browsing through the archives I found this post of yours. I am now
> working exactly on the same kind of SSL proxy you described, and I'm
> stuck exactly on the sa
Carlos Vicente <[EMAIL PROTECTED]> writes:
> Browsing through the archives I found this post of yours. I am now
> working exactly on the same kind of SSL proxy you described, and I'm
> stuck exactly on the same problem. It's clear that browsers initiate
> the SSL session --sending the ClientHell
>
> Have you found any other solution to this? I would appreciate your
> help.
>
Here an idea:
- You create an https proxy (it may also be an http proxy) running
on localhost.
- The proxy is actually a CA. when it receives a connect request,
it creates on the fly a server certificate sig
Carlos Vicente wrote:
Hi Allan,
As far as I am aware an proxy server must support the CONNECT
method, and this is what a Client will use to establish a connection
on a port other than 80
Browsing through the archives I found this post of yours. I am
now
working exactly on the same kind of SS
13 matches
Mail list logo
