Re: OpenSSL handling intermediate certificates
On Sun, 12 Aug 2012 13:29:57 -0400 Nico Kadel-Garcia wrote: > Such certificates have already been stolen. They're dependent on the > security of the intermediate key owners, and the are demonstrably > unsecure: Check this URL for more details on the release of rogue SSL > signing certificates through a Dutch firm: > > > http://www.computerworld.com/s/article/9219606/Hackers_stole_Google_SSL_certificate_Dutch_firm_admits > So why isn't there a good way for an end user to strictly limit trust in, for example, a "Google Internet Authority" to those domains that are actually owned by Google, and conversely, not to trust any other authority to sign certs for domains owned by Google? A single organization is about as far as I'd ideally want to extend trust at any one time anyway, and only for what I trust that organization for, because this whole SSL/x.509/PKI thing superficially appears to be hierarchical, but (as you've pointed out) in reality there is no hierarchy, because there are no limits to how far the trust is extended once we have these unknown intermediate certs. And just earlier this year, we're informed of a rather interesting "common industry practice": http://www.computerworld.com/s/article/9224082/Trustwave_admits_issuing_man_in_the_middle_digital_certificate_Mozilla_debates_punishment So you can close the barn door all you want with revocation, but that won't bring the cows back home from this particular pasture.
RENTAMOS SALONES PARA; CAPACITACIONES, CONGRESOS, EXPOS, CONFERENCIAS, CASTINGS, RECLUTAMIENTO
RENTAMOS SALONES PARA; CAPACITACIONES, CONGRESOS, EXPOS, CONFERENCIAS, CASTINGS, RECLUTAMIENTO Y SELECCION, RUEDAS DE PRENSA, PRESENTACIONES DE LIBROS, PRESENTACIONES DE DISCOS, JUNTAS ESTRATEGICAS. TAMBIEN PUEDES HACER EVENTOS PRIVADOS; FAMILIARES (XV AÑOS, DESPEDIDAS DE SOLTERAS, GRADUACIONES, PETICIONES DE MANO, ETC.), EMPRESARIALES; GALAS, COMIDAS, ANIVERSARIOS, CONVENCIONES, ETC.). SI VIENES DE PROVINCIA; CITAR PROVEEDORES, PARTNER´S, JUNTAS ESTRATEGICAS. SI TIENES UN GRUPO POLITICOS; REUNIONES PRIVADAS. NUESTRO CORPORATIVO, EN DONDE PONEMOS A TUS ORDENES 27 SALONES DE DIVERSAS CAPACIDADES, DESDE 3 Y HASTA 150 PERSONAS. ESTAMOS EN LA MEJOR, MAS COMUNICADA, CON LA MEJOR INFRAESTRUCTURA Y MAS SEGURA ZONA DEL PAÍS: INSURGENTES SUR 1223, ESQUINA SUR DEL PARQUE HUNDIDO, COL. EXTREMADURA INSURGENTES, DELEG. BENITO JUÁREZ, MÉXICO, CITY. CP.03740 CONTRATA YA!!!, TELS: 56119709, 56111841, 55637420 y 55986212. MAIL; renta.salo...@oyapac.com NUESTRA WEB: WWW.OYAPAC.COM RESERVACIONES Y CONTRATACIONES DE LUNES A VIERNES DE 10:00 A 19:00
Le Duc Toan đã để lại cho bạn 1 tin nhắn
Xin chà o, Le Duc Toan Äã gá»i má»t tin nhắn cho bạn Nháºn thÆ° từ Le Duc Toan!: http://myzamana.net/l?secret=360975382_a6b25eeb78b30523 Chúc vui vẻ! Äá»i ngÅ© myZamana Bạn Äã nháºn Äược email nà y vì má»t thà nh viên myZamana Äã gá»i má»t tin nhắn cho bạn. Äây là há»p thÆ° chá» cho phép gá»i. Trả lá»i cho tin nhắn nà y sẽ không Äược giám sát hay nháºn Äược trả lá»i. Không muá»n nháºn những email nhÆ° vầy trong tÆ°Æ¡ng lai? http://myzamana.net/u?i=360975382&h=a6b25eeb78b30523
Building i386 -cureent Userland failed
Hi Misc@, When I tried to build userland on i386 -current, the following error occur; /usr/src/kerberosV/usr.bin/klist/../../src/kuser/klist.c: In function 'display_tokens': /usr/src/kerberosV/usr.bin/klist/../../src/kuser/klist.c:496: error: 'VIOCGETTOK' undeclared (first use in this function) /usr/src/kerberosV/usr.bin/klist/../../src/kuser/klist.c:496: error: (Each undeclared identifier is reported only once /usr/src/kerberosV/usr.bin/klist/../../src/kuser/klist.c:496: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/kerberosV/usr.bin/klist: Exit status 1 (klist.o, line 89 of /usr/share/mk/sys.mk) Stop in /usr/src/kerberosV/usr.bin: Exit status 2 (all, line 48 of /usr/share/mk/bsd.subdir.mk) Stop in /usr/src/kerberosV: Exit status 2 (all, line 48 of /usr/share/mk/bsd.subdir.mk) Stop in /usr/src: Exit status 2 (all, line 48 of /usr/share/mk/bsd.subdir.mk) *** Error code 2 *** Error code 2 *** Error code 2 *** Error code 2 Stop in /usr/src: Exit status 2 (build, line 80 of Makefile) Any hints how to fix this? Thanks, Insan Praja SW -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Welcome to myZamana!
Welcome to myZamana! Your account has been setup. Now, follow these tips to get started: Add photos of yourself! http://myzamana.net/account?i=361671669&h=813737fcee79f2b9 The more photos you add, the more people will see you! Edit your profile http://myzamana.net/5651240?i=361671669&h=813737fcee79f2b9 Show people how interesting you are :) Find your friends on myZamana! http://myzamana.net/import?i=361671669&h=813737fcee79f2b9 5,650,343 people are on myZamana â Find out which of your friends are already here! Sign in to myZamana and start meeting new people: Your sign in details Email: misc@openbsd.org Password: 971bmkmo Please keep your sign-in details somewhere safe. If clicking the links in this message does not work, copy and paste them into the address bar of your browser: http://myzamana.net/upload.php?i=361671669&h=813737fcee79f2b9 Have fun! The myZamana Team
Re: Building i386 -cureent Userland failed
Insan Praja SW wrote:
> /usr/src/kerberosV/usr.bin/klist/../../src/kuser/klist.c:496: error:
> 'VIOCGETTOK' undeclared (first use in this function)
> Any hints how to fix this?
This might be enough. My build is still running...
Index: kerberosV/src/lib/kafs/kafs.h
===
RCS file: /cvs/src/kerberosV/src/lib/kafs/kafs.h,v
retrieving revision 1.9
diff -u -p -r1.9 kafs.h
--- kerberosV/src/lib/kafs/kafs.h 23 Aug 2012 06:42:54 - 1.9
+++ kerberosV/src/lib/kafs/kafs.h 23 Aug 2012 14:21:15 -
@@ -54,6 +54,7 @@ struct ViceIoctl {
#endif /* _VICEIOCTL */
#define VIOCSETTOK _VICEIOCTL(3)
+#define VIOCGETTOK _VICEIOCTL(8)
#define VIOCUNLOG _VICEIOCTL(9)
#define VIOC_FILE_CELL_NAME_VICEIOCTL(30)
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: OpenSSL handling intermediate certificates
On Thu, Aug 23, 2012 at 01:37, Justin N. Lindberg wrote: > So why isn't there a good way for an end user to strictly limit trust > in, for example, a "Google Internet Authority" to those domains that > are actually owned by Google, and conversely, not to trust any other > authority to sign certs for domains owned by Google? The people designing the protocol never got that far. Anyway the workaround du jour is certificate pinning. Your browser is supposed to remember the cert used for the previous connection and warn if it changes, which reduces the window of opportunity.
Re: OpenSSL handling intermediate certificates
On Thu, Aug 23, 2012 at 12:08 PM, Ted Unangst wrote: people designing the protocol never got that far. > > Anyway the workaround du jour is certificate pinning. Your browser is > supposed to remember the cert used for the previous connection and > warn if it changes, which reduces the window of opportunity. > And a poor workaround at that. The only browser this works well in is Chrome, and only with Google properties. In Firefox, the Certificate Patrol add-on is bothersome to the user as it constantly asks permission, to the point of crying wolf. Large organizations with multiple certificates for the same site, such as Google and Microsoft, are not understood by this add-on. Firefox 17 is working towards a native certificate pinning feature. I hope the release of that feature works well and spurs other browser vendors to follow suit. One thing I've never understood is that if you're MITM'd, what good is a cert revocation going to do? The proxying individual can easily block access to the revocation lists, and your browser be none the wiser. 'DNS-based Authentication of Named Entities', in my opinion, is a more promising system than certificate pinning, as it allows web site operators to publish certificates (or hashes of them) in DNS. However, this would require DNSSEC to be secure (which itself seems to be mired in controvery lately, not to mention the slow rate of adoption), and the project at IETF appears to be mostly dead: https://datatracker.ietf.org/wg/dane/charter/
Re: OpenSSL handling intermediate certificates
On Thu, Aug 23, 2012 at 13:12, Ryan Kirk wrote: > One thing I've never understood is that if you're MITM'd, what good is > a cert revocation going to do? The proxying individual can easily > block access to the revocation lists, and your browser be none the > wiser. hahaha, I've seen exactly one program complain about being unable to contact the revocation server. The fucking java auto updater on windows for some reason can never make contact. > 'DNS-based Authentication of Named Entities', in my opinion, is a more > promising system than certificate pinning, as it allows web site > operators to publish certificates (or hashes of them) in DNS. However, > this would require DNSSEC to be secure (which itself seems to be mired > in controvery lately, not to mention the slow rate of adoption), and > the project at IETF appears to be mostly dead: > https://datatracker.ietf.org/wg/dane/charter/ I'm not sure if this is the same proposal as the one I saw before, but this is what really sold me on dnssec. dns is a naturally delegated hierarchy, it adapts well to a trust hierarchy.
Re: OpenSSL handling intermediate certificates
On 08/23/12 20:05, Ted Unangst wrote: > On Thu, Aug 23, 2012 at 13:12, Ryan Kirk wrote: >> One thing I've never understood is that if you're MITM'd, what good is >> a cert revocation going to do? The proxying individual can easily >> block access to the revocation lists, and your browser be none the >> wiser. > > hahaha, I've seen exactly one program complain about being unable to > contact the revocation server. The fucking java auto updater on > windows for some reason can never make contact. You could set security.OCSP.require to true in about:config in firefox. The result is hilarious... (well, it was for me ~1.5 years ago, never tried it again.)
