News for hackers. Stuff that matters.

jcase

Re:EMudhra Intermediate CA Compromise on Tuesday October 20, 2026 @07:28PM (#50174108)
I’ve asked this question before and the answer was that not all HSMs support it and they're too expensive to replace.
Thanks. You're right. Now I'm just wondering what IdenTrust gains from free DV certificates.
Acceptance into Mozillaʼs CA Certificate Program is usually discussed in public. Let's encrypt is not on the list of pending CA applications[0]. Does anyone know if they are introducing a new root certificate or teaming up with an existing CA?

[0] https://wiki.mozilla.org/CA:PendingCAs

Re:Stupid certificate tricks on Saturday May 09, 2015 @09:30PM (#9518390)
Running the openssl s_client command from the article will show you live.
Re:Researching a new form of HTTP caching optimization on Saturday January 10, 2015 @03:12PM (#8867763)
When you mentioned discourse serving 19k req/sec, does it hit the ruby stack at all? If no, serving 19k req/sec of cached HTML doesn't seem that impressive. What am I missing?
You're (almost) describing certificate pinning. Have a look at http://tack.io although it appears down for the moment. Here is the HN thread: https://news.ycombinator.com/item?id=4010711
With SSH you usually own both endpoints (or at least trusting your cloud provider).

The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.

I'm putting my eggs on certificate pinning.

This article[0] is largely about DNSSEC and DANE but it might give you some insights why making registrars the sole authorities isn't such a good idea.

[0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

Re:Why is FreeBSD deprecating GCC in favor of Clang/LLVM? on Tuesday August 13, 2013 @09:30PM (#6209476)
Well, whatever the license, here is to a bright future! That a rising tide may lift all boats.
Re:Why is FreeBSD deprecating GCC in favor of Clang/LLVM? on Tuesday August 13, 2013 @07:35PM (#6209020)
I'm not sure this is true (anymore?). There are many open source projects who are thriving under non copyleft licenses.

If someone wanted to be a dick about it they could release modified GPL code as one big diff and publish it on some obscure webpage only their customers have access to. Instead we see more and more companies and individuals becoming friendly open source citizens. Perhaps some because the GPL mandates it but I would like to think mainly because they feel it's right thing to do—copyleft or not.

Re:Why is FreeBSD deprecating GCC in favor of Clang/LLVM? on Tuesday August 13, 2013 @07:25PM (#6208987)
Not sure if you mean for profit and proprietary or just making money in general. For some reason though a lot of people think you can't sell GPL'd software which you absolutely can.
Re:Decentralized SSL cert verification on Sunday July 14, 2013 @07:54PM (#6042799)
DANE isn't without its own problems. Moxie Marlinspike wrote an excellent blog post about it.

http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

Re:Decentralized SSL cert verification on Sunday July 14, 2013 @07:41PM (#6042754)
If users can't configure their Facebook privacy settings I'm not too optimistic about their ability to manage root certificate trust bits. It's a good start though.

Ideally OS/Browser vendors would drop compromised CAs. That happened with DigiNotar. It's not always an option though — the three largest CAs have a 83.97%[0] market share. Dropping any one of them breaks the internet.

Unfortunately a lot of people seem hell bent on destroying rather than improving on top of it.

[0] https://ssl.netcraft.com/ssl-sample-report/CMatch/certs

Re:Decentralized SSL cert verification on Sunday July 14, 2013 @11:37AM (#6041131)
Sounds very similar to Convergence. In fact, it turns out that "Convergence is based on previous work from the Perspectives Project at Carnegie Mellon University".[0] I don't think this (or Convergence) will see widespread adoption though. For now, public key pinning (e.g. Tack.io) seems like the best way forward.

For what it's worth, many CA's are trying to raise the bar by way of the CA/Browser Forum.[1] The public mailing list is quite interesting at times.

[0] https://en.wikipedia.org/wiki/Convergence_(SSL)#Background

[1] https://www.cabforum.org

Same version, no warning. Edit: Oops, had yet to read that it's now temporarily whitelisted by google.
Re:Show HN: Like Airbnb but for food on Wednesday May 22, 2013 @02:18PM (#5752752)
Interesting, thanks!
Re:Show HN: Like Airbnb but for food on Wednesday May 22, 2013 @01:09PM (#5752243)
When the EU region was announced[1] last month they weren't Safe Harbor compliant (yet). Has that changed?

[1] https://blog.heroku.com/archives/2013/4/24/europe-region (near the bottom).

Re:Bad as Shit on Monday May 13, 2013 @11:27AM (#5699180)
For some reason it reminded me of "The Electronic Money Mill". Original site is gone but The Internet Archive has a copy: http://web.archive.org/web/20080412233535/http://www.msen.co...

Fun (semi-fictional) read about Electronic Funds Transfer, crypto and the FBI.

The Luna SA they are using doesn't come cheap. For an H/A setup with all the extras (backup tools, service contract) I was quoted ~$80k.
Re:Announcing MoSQL on Tuesday February 05, 2013 @01:54PM (#5172446)
Automatic failover is a pretty big feature though. I wish Postgres had a built-in solution. Sure, I could use Pacemaker but it's no where near as painless.
Re:Limiting passwords to 12 characters is "secure enough" on Friday February 01, 2013 @04:47AM (#5150014)
It's 72 actually. I thought it was 56 as mentioned on the original [?] BCrypt website[1]. A thread[2] on security/stackexchange discusses a workaround for the 72 char limit. See https://gist.github.com/4690368 for a simple test case that shows the >72 char truncation.

The source provides a hint:

    /* Schneier specifies a maximum key length of 56 bytes.
    * This ensures that every key bit affects every cipher
    * bit.  However, the subkeys can hold up to 72 bytes.
    * Warning: For normal blowfish encryption only 56 bytes
    * of the key affect all cipherbits.
    */
[1] http://bcrypt.sourceforge.net/

[2] http://security.stackexchange.com/questions/21524/bcrypts-72...

Indeed. Chrome has baked-in public key pinning for their services.

http://www.imperialviolet.org/2011/05/04/pinning.html

For domain validated certs, certainly.

The issue is that it doesn't solve anything. We merely shift (more) responsibility to registrars and NICs. You can change (untrust) registrars I suppose but if you have a .com you'll have to trust Verisign _forever_. Well, at least as long as they operate the .com tld. So if Verisign loses your trust, there is even less you can do than today.

Actually, I've thought about starting a "real" CA (read: get certified etc). I'm not sure the world needs another one though.

Your experience running a homebrew setup is exactly why I think CAs will continue to exist—even if self-signed certs would be widely supported via DANE. I doubt many businesses are going to run their own CA in order to save < $1000 a year.

> Consider this, if I hold a certificate for fubar.com, why am I not permitted to issue a certificate for xyz.fubar.com Or, better yet - another certificate for fubar.com?

Because business model. StartSSL.com is afaik the first (only?) CA that charges solely for identity validation and then let's you create unlimited (wildcard) certificates (with the exception of EV certs).

* No ties, just a customer.

Some developments in this area are:

* Convergence.io

* DNS-based Authentication of Named Entities (DANE) + DNSSEC

* Tack.io

For various reasons listed in [1] Convergence is not likely to be implemented (by default) in major browsers.

On DANE + DNSSEC, where the cert is authenticated via the information published in your DNS, Moxie Marlinspike has said it better then I can:

    "CAs are sketchy, but this is a whole new world of sketchiness. Think,
    sketchasaurus. Registrars were never built or selected with security in mind,
    and most of them don’t have a very good track record in this area. Shouldn’t it
    be laughable that the current first step in deploying DNSSEC is to create an
    account with GoDaddy?"[2]
The 2011 BlackHat video[3] and blog post[2] by Moxie Marlinspike are great sources of information.

IMO, Tack.io is the most viable solution. It's compatible with the current model but removes the thread of one CA being able to compromise all domains.

[1] http://www.imperialviolet.org/2011/09/07/convergence.html

[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

[3] http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Did you look at Braintree?

Older »