Hacker News Reader

Comment by karel-3d | Hacker News Reader

I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL. Which excluded Let's Encrypt.

We were looking for a SSL provider that had > 1 year old certs AND supported ACME... for some reason we ended up with SSL.com that did support ACME for longer lasting certs; however, there was some minor incompatibilities in how kubernetes cert-manager implemented ACME and how SSL.com implemented ACME; we ended up debugging SSL.com ACME protocol implementation.

Fun. We should have just clicked once per 3 years, better than debugging third parties APIs.

No, I don't remember the details and they are all lost in my old work emails.

(Nowadays I think zerossl.com also supports ACME for >1 year certs? but they did not back then. edit: no they still don't, it's just SSL.com I think)

View on HN

> I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL

Why are (some) banks always completely clueless about these things? Validating ownership of the domain more often (and with an entirely automated provisioning set-up that has no human weak links) can only be a good thing.

Perhaps the banking sector will finally enter the 21st century in another ten years?

The problem is more likely one of regulation than technical knowledge. Banks hire very smart people who know that a lot of what they do is bullshit, but they're paid to comply with banking and security regulations that lag a long way behind technical advances. Banks are also inherently conservative in their technical choices, and for good reason.

The banking sector usually goes with "checkbox security".

They have these really, really long lists what all needs to be secured and how. Some of it is reasonable, some of it is bonkers, there is way too much of that stuff, and it overall increases the price of any solution 10x at least.

But OTOH I can hardly blame them, failures can be catastrophic there, as they deal with real money directly and can be held liable for failures. So they don't really care about security, and more about covering their asses.

> some of it is bonkers

Some of it is truly bonkers and never was good practise, but much of the irritating stuff is simply out-of-date advice. The banks tend to be very slow to change unless something happens that affects (or directly threatens to affect) the bottom line, or puts them in the news unfavourably.

Of course some of it is bonkers, like HSBC and FirstDirect changing the auth for my personal accounts from “up to 9 case-sensitive alpha-numeric characters” (already considered bad practise for some years) to “6 digits”, and assuring me that this is just as secure as before…

That sounds like "we were truncating your id and pass before anyway".

I don't think so, because it would also imply they were also throwing away anything non-numeric, and I really hope nothing that stupid was going on. When the change happened everyone had to establish a new password.

I read it as “we have been asked to integrate an ancient system that we can't update (or more honestly in many cases: can't get the higher-ups to agree to pay to update), so are bringing out other systems down to the lowest common denominator”. That sort of thing happens too often when two organisations (or departments within one) that have different procedures, merge or otherwise start sharing resources they didn't previously.

I won't go into the idiocies banks implement. They usually have to because totally incompetent people tell them they have to.

One of the practices was pathetic to the point of being funny: you had to input specific characters of your password (2nd, 4th, 6th, etc - this was changing at each login) AND there was a short timeout. My children probably learned a few new words when I was logging in.

I suppose the purpose of that was to signal to hackers that they ARE in fact storing all passwords in plaintext?

It is very likely, yes. After a year or so of this practice (people were writing down their password with digits under the letters to quickly match the request) the bank said that they now propose two "secure login forms" - the older one and a new, normal one.

Some time later they silently removed the first one.

Tsb bank in the UK still do exactly this

> I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL. Which excluded Let's Encrypt.

I wonder if this would be an opportunity for revenue for Let's Encrypt? "We do 90-day automated-renewal certificates for free for everyone. If you're in an unusual environment where you need certificates with longer validity, we offer paid services you can use."

Probably better to keep LE / ISRG completely non-profit. Adding a profit motive has too big of a chance to end with actually security-relevant features being gated behind payment eventually.

It's less about the profit motive, and more about removing the remaining incentives to stay outside the ACME ecosystem. The funding would be to provide additional infrastructure (e.g. revocation servers for longer-lasting certificates), and to fund new such efforts.

But once there is an income stream from issuing certificates there is an incentive to increase it which will quickly find itself at odds with the primary missions of providing secure connections to as many people as possible. Making infrastructure depend on that income stream only increases that incentive. Perhaps you trust the ISRG to resist the temptaton but as far as I know they are run by humans.

There are many, many opportunities in both the business and non-profit world to make more money by screwing your customers/users, and despite that, it does not always happen. Businesses and non-profits are built on the trust of users (or built in spite of the utter lack of it, e.g. Comcast). I don't think they should be afraid to provide things users need. It is, in fact, possible to choose and keep choosing to maintain the trust of your users.

I think there's still incentive alignment here. Getting people moved from the "purchase 1 year certificate" world (which is apparently still required in some financial contexts) into the ACME-based world provides a path for making a regulatory argument that it'd be easy for such entities to switch over to shorter-lived certificates because the ACME infrastructure is right there.

If they want to do something commercial, they should go for the code signing certificates, that stuff is still a racket.

I'm pretty sure ISRG doesn't want to deal with payments any more than they do now (i.e. outside of donations and sponsorships)

Globalsign and digicert have acme support.

Hm, I have no idea why we didn't pick tgem back then. I see it now. Maybe it was too expensive? I don't remember the reasoning at this point

Reply on news.ycombinator.com