[Mono-list] Certificate validation in HttpWebRequest
argemat1010 at gmail.com
Tue Mar 25 09:27:43 UTC 2014
After some sniffing in wireshark, I found that the handshake request is
missing the "renegotiation info" (RI) extension, which is required by the
server for safety reasons. Is there some way to turn it on?
On Monday 24. March 2014 11:24:29 you wrote:
> I just found the cause of the error, it is different then what I assumed
> first. The server I was using for my tests only allows connection via TLS
> v1.1 v1.2 and a quick peak into the source code
> ty/SslStream.cs#L316 and
> thentication/SslProtocols.cs#L41 ) revealed, that while .NET supports those
> newer protocols since 4.5, Mono is only able do deal with SSLv3 and
> That's quite a huge security problem, should I open a bug for it, or is it
> already tracked, since it is marked with MonoTodo?
> On Friday 21. March 2014 13:43:49 Edward Ned Harvey wrote:
> > > From: mono-list-bounces at lists.ximian.com [mailto:mono-list-
> > > bounces at lists.ximian.com] On Behalf Of Mat Arge
> > >
> > > I do access some websites on HTTPS URLs using the HttpWebRequest class.
> > > To
> > > handle the certificates I set the
> > > System.Net.ServicePointManager.ServerCertificateValidationCallback to an
> > > implementation of mine. This worked fine, but recently (to be precise:
> > > since
> updating from mono-2.10 to 3.2.8) I get the old
> > > "System.Net.WebException: Error getting response stream (Write: The
> > > authentication or decryption has failed.)" error again. My callback is
> > > actually never called.
> > I recently stepped into the same problem, only I was using SslStream
> > rather
> > than HttpWebRequest, and thanks to Sebastien for steering me straight.
> > I don't know if HttpWebRequest is using SslStream under the hood? Here
> > was
> > the answer for SslStream. I'm highly suspicious that it's related.
> > Check the mono compatibility page. (Just google for "mono
> > compatibility").
> > At the bottom, go to "class status pages" and then System,
> > System.Net.Security, SslStream. Notice that the basic constructor
> > (without
> > RemoteCertificateValidationCallback) is green and good. While the ones
> > with callback are marked as not returning SslPolicyErrors correctly. The
> > solution for me was to use the basic constructor, and then if
> > AuthenticateAsClient failed, try again using the other constructor, but
> > ignore the SslPolicyErrors and Chain.
> > Looking at HttpWebRequest right now, I don't see anything obviously along
> > those lines. It is very likely you are encountering *some* bug or
> > incomplete feature. Can you post some sample code? That would make it
> > easier to say for sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 665 bytes
Desc: This is a digitally signed message part.
More information about the Mono-list