Menu
▾
▴
amsn-devel
|
From: Álvaro J. I. <air...@us...> - 2010-03-08 17:42:21
|
I didn't know about this problem with the certificate. Sounds easy to fix, maybe just check certificate signature, and give a warning if mismatch? what do you think? ---------- Forwarded message ---------- From: Jan Lieskovsky <jli...@re...> Date: Mon, Mar 8, 2010 at 6:31 PM Subject: Regarding aMSN SSL Certificate Validation Security Bypass issue To: "Alvaro J. Iradier Muro" <air...@us...> Hi Alvaro, this is due: [1] http://www.juniper.net/security/auto/vulnerabilities/vuln35507.html [2] http://seclists.org/bugtraq/2009/Jun/239 Noticed aMSN 0.98.3 was released today: [3] http://www.amsn-project.net/blog/2010/03/amsn-0-98-3-released/ but i can't see patch for [1] in it, so wanted to check the state of it with you -- is the aMSN upstream planning to address this issue? (Or has it already been addressed and i just overlooked the change?) Thanks && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- (:=================================:) Alvaro J. Iradier Muro - air...@gm... |
|
From: Youness A. <kak...@ka...> - 2010-03-08 18:04:33
|
Hi, I remember looking at the 'how to validate certificates with tcl-tls' a while ago, it's not really hard, but it will probably be annoying to do it.. especially considering the http stuff, and in cases of proxies (the code and API used for proxies is different).. there are so many tls connections to so many different servers, each might have their own certificate, and since for http we can only set it up via 'http::register' for the port 443, if we do two parallel connections, we might have easily a race condition where the wrong certificate is being checked... Also, if the M$ certificate expires and they change it, it will break all version and will force us to release a new version (and you know it takes us months to do one release, even in 'release ASAP' mode). And distributions that don't update their repositories very often will suffer from it.. But I'm not too sure of how this stuff works though. Other solution might be to provide a directory with the CA certicates, and let tcltls validate the CA from there.. I'm not sure, and I'm not very security-savvy, so if someone else volunteers to do it... that would be nice. Best solution would be to say : Jan Lieskovsky, patches are welcome :) KaKaRoTo On Mon, Mar 8, 2010 at 12:42 PM, Álvaro J. Iradier < air...@us...> wrote: > I didn't know about this problem with the certificate. > > Sounds easy to fix, maybe just check certificate signature, and give a > warning if mismatch? what do you think? > > > ---------- Forwarded message ---------- > From: Jan Lieskovsky <jli...@re...> > Date: Mon, Mar 8, 2010 at 6:31 PM > Subject: Regarding aMSN SSL Certificate Validation Security Bypass issue > To: "Alvaro J. Iradier Muro" <air...@us...> > > > Hi Alvaro, > > this is due: > [1] http://www.juniper.net/security/auto/vulnerabilities/vuln35507.html > [2] http://seclists.org/bugtraq/2009/Jun/239 > > Noticed aMSN 0.98.3 was released today: > [3] http://www.amsn-project.net/blog/2010/03/amsn-0-98-3-released/ > > but i can't see patch for [1] in it, so wanted to check the state of > it with you -- > is the aMSN upstream planning to address this issue? (Or has it > already been addressed > and i just overlooked the change?) > > Thanks && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Response Team > > > > -- > (:=================================:) > Alvaro J. Iradier Muro - air...@gm... > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amsn-devel mailing list > Ams...@li... > https://lists.sourceforge.net/lists/listinfo/amsn-devel > |
|
From: Álvaro J. I. <air...@gm...> - 2010-03-08 18:18:12
|
On Mon, Mar 8, 2010 at 7:03 PM, Youness Alaoui <kak...@ka...> wrote: > Hi, > I remember looking at the 'how to validate certificates with tcl-tls' a > while ago, it's not really hard, but it will probably be annoying to do it.. > especially considering the http stuff, and in cases of proxies (the code and > API used for proxies is different).. there are so many tls connections to so > many different servers, each might have their own certificate, and since for > http we can only set it up via 'http::register' for the port 443, if we do > two parallel connections, we might have easily a race condition where the > wrong certificate is being checked... I don't know how the connection is done right now, but I guess we should check that the server provided certificate ir signed by a valid CA, and that the cn (common name) of the certificate is the hostname we are connecting to (or are we using an IP address?). Another option is just to collect the fingerprints of all expected certificates and check against that list. tcl-tls works with OpenSSL, so I wonder if OpenSSL does include a list of valid CAs, and then probably tcl-tls is doing the verification. According to the docs: http://www.flightlab.com/~joe/gutter/doc/tls-1.5/tls.htm#CALLBACK%20OPTIONS the verify function callback includes a "status" argument: "The status argument is an integer representing the current validity of the certificate. A value of 0 means the certificate is deemed invalid. A value of 1 means the certificate is deemed valid. " It would be worth checking if this is already verifying the validity of the certificate. > Also, if the M$ certificate expires and they change it, it will break all > version and will force us to release a new version (and you know it takes us > months to do one release, even in 'release ASAP' mode). And distributions I was thinking about "warning the user", just show a dialog telling the certificate is invalid, blah blah blah. > that don't update their repositories very often will suffer from it.. But > I'm not too sure of how this stuff works though. > Other solution might be to provide a directory with the CA certicates, and > let tcltls validate the CA from there.. I'm not sure, and I'm not very yes... I'm just wondering if tcl-tls already does this. If not, we could check what CAs is Microsoft using for certificate expedition, and just verify the certificates against this CAs's certificates :p > security-savvy, so if someone else volunteers to do it... that would be > nice. I'm afraid I won't have much time in march. (I wake up at 7 every day and I'm back at home at 22:30). But I can help with the discussion writing mails in the coffee breaks :p > Best solution would be to say : Jan Lieskovsky, patches are welcome :) More than welcome... Greets. > KaKaRoTo > On Mon, Mar 8, 2010 at 12:42 PM, Álvaro J. Iradier > <air...@us...> wrote: >> >> I didn't know about this problem with the certificate. >> >> Sounds easy to fix, maybe just check certificate signature, and give a >> warning if mismatch? what do you think? >> >> >> ---------- Forwarded message ---------- >> From: Jan Lieskovsky <jli...@re...> >> Date: Mon, Mar 8, 2010 at 6:31 PM >> Subject: Regarding aMSN SSL Certificate Validation Security Bypass issue >> To: "Alvaro J. Iradier Muro" <air...@us...> >> >> >> Hi Alvaro, >> >> this is due: >> [1] http://www.juniper.net/security/auto/vulnerabilities/vuln35507.html >> [2] http://seclists.org/bugtraq/2009/Jun/239 >> >> Noticed aMSN 0.98.3 was released today: >> [3] http://www.amsn-project.net/blog/2010/03/amsn-0-98-3-released/ >> >> but i can't see patch for [1] in it, so wanted to check the state of >> it with you -- >> is the aMSN upstream planning to address this issue? (Or has it >> already been addressed >> and i just overlooked the change?) >> >> Thanks && Regards, Jan. >> -- >> Jan iankko Lieskovsky / Red Hat Security Response Team >> >> >> >> -- >> (:=================================:) >> Alvaro J. Iradier Muro - air...@gm... >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Amsn-devel mailing list >> Ams...@li... >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amsn-devel mailing list > Ams...@li... > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > -- (:=================================:) Alvaro J. Iradier Muro - air...@gm... |
|
From: Sander H. <sa...@ho...> - 2010-03-09 21:17:28
|
On Mon, 2010-03-08 at 19:18 +0100, Álvaro J. Iradier wrote:
> On Mon, Mar 8, 2010 at 7:03 PM, Youness Alaoui
> <kak...@ka...> wrote:
> > Hi,
> > I remember looking at the 'how to validate certificates with tcl-tls' a
> > while ago, it's not really hard, but it will probably be annoying to do it..
> > especially considering the http stuff, and in cases of proxies (the code and
> > API used for proxies is different).. there are so many tls connections to so
> > many different servers, each might have their own certificate, and since for
> > http we can only set it up via 'http::register' for the port 443, if we do
> > two parallel connections, we might have easily a race condition where the
> > wrong certificate is being checked...
>
> I don't know how the connection is done right now, but I guess we
> should check that the server provided certificate ir signed by a valid
> CA, and that the cn (common name) of the certificate is the hostname
> we are connecting to (or are we using an IP address?).
>
package require tls
proc debug args { puts [info level 0] }
set s [::tls::socket -command ::debug -cafile /etc/pki/tls/certs/ca-bundle.crt -request 1 -require 1 login.live.com 443]
puts [::tls::handshake $s]
puts [::tls::status $s]
This code works for me, to test.
We need to have 1 as return from ::tls::handshake, and from the output
of status we can get the CN of the subject, and compare that against the
hostname.
-cafile on a debian system is
probably /etc/ssl/certs/ca-certificates.crt
HTH, Tjikkun
|
|
From: Boris 'b. F. <bi...@gm...> - 2010-03-10 12:39:36
|
I've added certificates in utils and added checks around ::tls::socket use in commit 11991. Please test. Greetings -- Boris 'billiob' Faure |
Thanks for helping keep SourceForge clean.
X