Security.txt file now mandatory for Dutch government websites | Hacker News Reader

Security.txt file now mandatory for Dutch government websites

netherlands.postsen.com

359 pointspseudotrash154 comments

> The aim is that, for example, ethical hackers can immediately contact the right person or department to tackle the vulnerability.

We added such a file years ago. There's still some security researchers ("bug hunters") not aware of the standard and email other email addresses (info@, invoice@, data-protection@). Nobody has ever used the GPG key we list in the security.txt file. The email address we list (security@) hasn't received any significant spam.

I've reported some bugs and one thing that I always hate is the GPG Key. It is always a huge hassle to use for some reason and for half of the time it doesn't even seem correct or the other party isn't even using it themselves anymore.

If you are an average person and you notice that changing the ID in the URL to another number gives you access to data you should not see; you aren't some elite hacker as many of the news articles try to portray you. So expecting from them to use a GPG Key while they only have their ISP provided webmail will be near impossible for them to do under half a days work.

Especially as most GPG tools are very unfriendly to use.

>Is it weird that I expected proof to be a PGP-signed message?

>I have not used PGP for many years, because it does not run on my iPhone[.]

- Phil Zimmermann, author of PGP

https://old.reddit.com/r/IAmA/comments/x3b3gj

> If you are an average person

This isn't for the average person.

Just yesterday there was a thread here, where a random user was added as admin for multiple accounts for GCP accidentally, and he couldn't talk to a human on Google to get it resolved. He was neither actively looking out for nor was not anything other than the average user. OP is correct PGP, is a hassle, and needs explicit knowledge to use it correctly. Keybase somewhat solved it then got unpopular, but thinking about it again even Keybase never went mainstream.

s/got unpopular/acquihired by Zoom and killed/

While I wouldn't call it "mainstream", Keybase got a lot of computer-literate but not IT people into PGP, which hasn't really happened before. It had a good chance to go mainstream, but I guess this ending was inevitable since it was a for-profit company after all...

I understand that the average Joe isn't going to be using pgp. But the kind of folks that go looking for a security.txt file will be able to figure it out.

Or, more likely, ignore it.

Touche

Why not? Many security issues are detected by people who just happened to do a series of actions in a way nobody expected them to do.

I clicked this "sudo" button and it changed my name in the app to "root".

You're underestimating how many average people or below-average hackers find/stumble-upon serious vulnerabilities all the time.

>Especially as most GPG tools are very unfriendly to use.

Install FlowCrypt (or Mailvelope) and it will become the easiest thing in the world. At least, that was my experience!

Even the dependency on email is looking a little outdated — at least that's not a requirement of security.txt though.

I think email is a good standard that you can safely assume will be there for the forseeable future. Many communication platforms come and go, email staied thare from Internet's beginning to today and shows no sign of disappearing. Plus you can safely assume that a person on the Internet has at least one email account (exeptions are extremely rare, often is even your ISP that gives you an email account), the same doesn't hold true for other plarforms like Discord.

Interesting - I guess I didn't get "significant" spam either, but after a dozen or so beg bounties I had enough of it and removed it again. And now it's back to roughly zero beg bounties. Serious security researchers won't have a hard time clicking "Contact" in my website header & sending an e-mail to that address anyways.

Beg bounties are getting more and more common.

What’s the best way to get things read? Prefix them with ‘I am NOT looking for payment, reward or bounty’?

Honestly, I at least glance at the beg bounties, but they're all so formulaic and bullshit it's easy to see what's up.

Once I was getting too many to glance at, hard to say. Probably mailing a physical letter to the address of record (if it's not a company and so has no address, not sure).

Just report the issue honestly, don’t try to obfuscate, and don’t send a message to a security@ with something like “I found a security issue” with no details of any kind.

If it’s not a security@ and not specifically listed as a security point of contact it’s fair to ask if it’s the right location for a potentially security-sensitive issue and whether there’s a better one.

Putting that at the front of your email makes it sound even more sketchy to me.

Once this goes mainstream I'm betting on massive spam. I'd only list the contact us url

> and email other email addresses

these are probably the people more interested in getting someone to sign off on a bug bounty than they are in getting hold of someone technical who might point out that the fact you can right click and edit the HTML to say "HACKED!!" isn't a bug...

A lot of people just don't care about writing to the right address. I did work for a university and the most random people would get emails aimed at completely different departments, staff or even a different university. I don't mean old people or clueless young students, I mean some press contacts, some other academics and people like that.

I very recently had a 'dont care about the write address' story -- which I think is worth remember for those of us that monitor some of these less-common but known-to-technical-people mailboxes....

When I had an issue with LastPass, the ONLY contact method they listed for support required you to log in and use their help form...

Since I used federated login, only the browser extension was supported -- not website login... So.. I can't log into their website for support, but I have to log into their website for support...

I went through a series of help@ support@ helpdesk@ contact@ and got bounces / "use our web form" responses... I then escalated to the other technical addresses like webmaster@ hostmaster@ until I finally tried to reach out to sales@ for the support issue...

So sometimes people do intentionally write to 'the wrong address' because there's no 'right address' (that's publicly known/available).

I'm skeptical that GPG encryption is really useful for such reports anyway. Any attacker with access to important email addresses that would receive such reports probably already has a higher level of access than whatever is being reported. And in the case of bug reports, I don't think being able to verify the sender is all that important.

The purpose of publishing your [company’s] public key is not only to verify the sender. It gives the sender a way to send an encrypted email that only the recipient can read (as long as they still have the key pair.)

Based on the limited public PGP key infrastructure, OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message. Being as certificates have to be renewed frequently and verified people would most likely have up-to-date keys.

Level of effort is roughly a one line openssl command for both encryption and decryption.

* I suppose though one thing I didn't consider is follow up messages or correspondence which using PGP would be easier, if everything is already working in your email client. Although it wouldn't be that difficult to include your public key in the initial message, which could be used for responding.

What you propose is basically a form that can be served over https.

Is there a bit more you can expand on this? A contact form only serves one-way communication and if its sending an email anyway what is the workflow improvement or additional confidentiality/integrity with regards to the message?

The workflow i'm thinking of would be encrypting text with the public key of the website/company you are reaching out to, including your public key in the message or if you have a website as a researcher you can provide the instructions of using your public key for them to send you a response. You then send them an email and attached your encrypted correspondence.

When they respond back they use whatever public key you provided in your initial message and you can decrypt their response. This doesn't require your email client to support PGP or have a keyring setup just simple openssl command(s) that work right from the terminal.

The original goal post was for the original sender to confidentially send a message to the website owners.

> OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message.

So a simple form over HTTPS achieves the security researcher -> company part. I agree that it's not sufficient on its own for a confidential two way communication channel, but it can also be achieved over the same technologies. But maybe implementing a messaging platform for the sole purpose of reporting security issues is overkill and could bring its own attack surface.

Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption. You might as well just put up a messaging dialog at a dedicated security endpoint that is accessible through the browser and let the researcher reuse the same messaging session in some robust way for an effective two-way secure communication channel (login, client certificate).

Yeah I was having the same thought on the web form and if it brings additional overhead maintenance, testing, etc which to me would be the same as trying to get some form of PGP working across mail clients.

> Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption.

This is the only part I would disagree with and it could be subjective based on your experience with certificates. Using openssl wouldn't really be ad-hoc as this is what certificates are for. If the researcher and the website owner already have certificates for their websites there isn't any other additional work as both public keys are available in the form of their site certificates. There are also a number of sites that provide instructions on generating self-signed certificates [1][2][3] as well as encrypting messages with public certs [4][5][6].

Oddly enough when looking for the (3) openssl commands for encrypting a message I came across this site which recommended using GPG for messages[4], however they all pre-suppose that you have everything setup for using GPG which usually isn't the case and using openssl, in my opinion, has reduced friction being as it doesn't depend on being integrated into a web or email client application, you can simply attach the generated encrypted message like any other email attachment.

The infrastructure concern is really the existing public key availability, accessibility and maintenance options for keys. If the public service is unreliable or lacking robustness then both software developers and individuals are less likely to use or integrate the implementation. There are only a few places to upload your pgp key to that are reliable, compared to the existing certificate system. On my last looking there were maybe (3) sites that were reliable[7] and MIT had been flaky for a while, leaving only two.

https://pgp.mit.edu/ https://keyserver.ubuntu.com/ https://keys.openpgp.org/

However, to your initial point I can certainly see a web interface being a better overall solution as the people set to receive these notifications may not be familiar with the command line or terminal interfaces let alone openssl commands.

Thanks for your response I enjoyed thinking through this.

----

References

[1] https://msol.io/blog/tech/create-a-self-signed-ssl-certifica... [2] https://devopscube.com/create-self-signed-certificates-opens... [3] https://www.digitalocean.com/community/tutorials/openssl-ess... [4] https://www.madboa.com/geek/openssl/#how-do-i-simply-encrypt... [5] https://gist.github.com/thinkerbot/706137 [6] https://www.czeskis.com/random/openssl-encrypt-file.html [7] https://superuser.com/questions/227991/where-to-upload-pgp-p...

I understand that. But I also said that I don't think encrypting the message has much of a benefit. I can't imagine many scenarios where a compromised email address would be less of a threat then reading the messages sent to that account.

A security researcher finds a server-side RCE vulnerability and discloses it to security@bigcorp.net. An attacker breaks into security@bigcorp.net because the password was the IT director's dog's name.

Don't you think being able to read that disclosure would give the attacker a bit more access to bigcorp's systems than if it was encrypted?

When the attacker already has the credentials of the IT Director? I doubt they will be too interested in bug reports, somehow...

You must be joking! Do you store all your SSH keys in your email? Do IT directors in big companies even have shell access to production servers? Even if, that would show in the audit logs, whereas an RCE is less likely to. And what if the bug is client-side??

They wouldn't have to have access or SSH keys. The position is usually at a level where people don't question requests or have a heightened guard with emails. It wouldn't be difficult to pivot to requesting an account made for some project or including an attachment that compromises a device which you have phone home. This is shown a number of times publicly with phishing emails that lead to breaches, gift cards scams and wire fraud.

In your proposed situation having access to the director of IT's email account is similar to physical access on a server. The RCE might be another layer of access but its not game changing to what is already available.

To get an idea of how well our government organisations get along with implementing this (and a lot of other basic security requirements, like TLS, IPv6, DNSSEC, etc) you can view these maps[0][1].

We maintain a set of open source tools to easily get you started[2]. If you would like help to have this for your country/government/organisation as well, feel free to contact us.

[0] https://basisbeveiliging.nl/#/metric-progress/NL/municipalit... [1] https://basisbeveiliging.nl/#/maps [2] https://gitlab.com/internet-cleanup-foundation/web-security-...

Is there an enforcement arm? As in, what if some agency decides not to do it for some reason - do they get sanctioned in any way? In the US Federal government, there are two I'm familiar with: budget and dragging agency heads in front of congress or the Executive Office and yelling at them. The first doesn't always work - cutting the budget of an important agency over what the press would call a "minor IT issue" doesn't look good (and counter productive). The second tends to work better.

Central government can force any covered entity to publish which standards they (do not) support, to produce an audit, and in the last instance, instruct them to comply. This is a specific provision on top of generic rules and regulations, where central government can step in the place of a lower government if they are non-compliant.

Also, citizens (or NGOs) can sue entities (including central government) for non-compliance. For example, in 2022, the NGO Urgenda won a case against the Dutch government for not doing enough about climate change (less than needed to comply with international treaties), and now the political landscape is in turmoil because there's no consensus which polluters should stop polluting quite as much.

In practice, the list of standards is just tacked onto procurement procedures. Since governments and contractors love to bicker, a missing security.txt can be something to hit the vendor over the head with (and withhold payment for a month, to make this year's budget).

>If you would like help to have this for your country/government/organisation as well, feel free to contact us.

I was looking into what exactly is need for this but the last link has this in the guide:

>For full installation with everything and anything, check: https://gitlab.com/internet-cleanup-foundation/server/

The link is broken.

I'm gonna look into that and come back to you.

edit: W're a small team and we can't allocate the time needed to make that repo decently public atm. For now it's best to drop an email at the adres found here [0] and I'll help you get along.

[0] https://internetcleanup.foundation/about-us/

Ooh, I've been wanting to do this for India for a long time. Got around to domain lists [1], [2], but never got around to publishing my scan reports. Will reach out.

[1]: https://gist.github.com/captn3m0/4f3da8f07fe884e62bfab3ac856...

[2]: https://git.captnemo.in/nemo/pulse

This has been discussed to death every time security.txt comes up, but in my experience it's been a great way to receive spam about bullshit "vulnerabilities" from low effort scanners operated by "security researchers".

Much like how people publish email addresses online using human readable replacements (e.g. AT instead of @) to avoid spam, I'd rather put up a contact page that's easy for humans to find but nontrivial to automate.

Most of those are trivial to filter. Mentioning SPF or DKIM -> straight to the bin. Contains "critical" and "payment" -> straight to the bin. There's few patterns you'll find that will let you remove all the beg bounties.

> Contains "critical" and "payment" -> straight to the bin.

That sounds like an excellent way to accidentally filter out serious vulnerabilities. I'm glad you don't work for the vendor that received my urgent, critical (in all caps) unauthenticated remote code execution vulnerability report.

They were very grateful that I reached out and resolved it under 72h.

Did you write "I found critical vulnerability on your website, how much is your bounty, can you send PayPal payment?"

If it wasn't something close to that, then no, it wouldn't be filtered. If it wasn't obvious, the patterns are trivial, but not "check those two words" level of trivial. You need to apply common sense and adjust for your environment.

Yep I have received a genuine report completely unsolicited before, paid a modest bounty and fixed the problem immediately, then took some precautions to ensure any potential data leaks were rendered innocuous.

I was very glad to have received the info and I think folks such as yourself are doing valuable work.

What if they're trying to report a critical issue with your payment processing?

Hint for applying ideas from comments: read information and understand the main point behind it, consider how it applies to your situation, then if it's beneficial try to implement it in a way relevant to you.

If you take comments like mine and try to implement them literally, that's stupid and it's on you.

Straight to the bin.

Obviously. >.<

Too bad, it's not my financial info at risk anyways. ;)

Why do SPF and DKIM go to the bin? I have just recently begun my initiation to the mysteries of email. Is it nonsense reports or something?

Depending on your application, setting up SPF and DKIM can be complicated. And typically not having it set up is not a security issue, it may affect deliverability of your outgoing email, but is not a vulnerability.

(and indeed many beg bounties are about SPF or DKIM, because whatever automated tools they use to find the low hanging fruit didn't find anything more substantial).

Of course it's a security issue, because having neither SPF nor DKIM means that malicious actors can all too easily impersonate your email addresses and phish users with an email that apparently came from your domain.

I occasionally get what I'm sure are very well meaning SPF/DKIM-missing reports for a domain that has a null mx record.

It can basically be assumed that anyone trying to report that didn't do even a basic cursory look at the results. I don't need your automated scan, I have my own nessus deployment and already know what it's going to say.

People can still malicously send emails in your name, even without an mx record.

Don't trust my word for this, have a look at CloudFlares article about this:

"How to protect domains that do not send email"

https://www.cloudflare.com/learning/dns/dns-records/protect-...

"null record" is not "no record". It's an MX record of priority "0" and value "."

No MTA will try to deliver a message that is from or to a domain that has a null record. If you're the sender, your sending MTA might give you an NDR, but receiving infrastructure will just drop it.

Cloudflare actually has a wizard that implements it in addition to the items on the page you linked. And no offense to whoever wrote the CF article, but they are the new kids on the block relative to email.

No offense but I think you got the meaning of the record wrong:

https://community.cloudflare.com/t/keep-null-mx-in-addition-...

> Null MX does nothing to prevent spoofing. It is just to signal to mail senders that your domain does not receive email.

And I also found multiple other sources that specify that the null record only announces that the domain does not receive email. After some googling I didn't find a single source that shares your explanation.

Having SPF/DKIM in DNS records doesn't prevent that.

This is exactly what SPF and DKIM are designed to do. DMARC enforces this.

Obviously, this is opportunistic security, the receiver must support all this, but >99% does.

Yes, but the public testers are not testing the receive side, but the sending side.

A large chunk of the beg bounty reports I see are "critical: your SPF is misconfigured, we'd like to share the details with you, how much are you paying".

There are, in fact, non-frivolous DKIM issues, such as DKIM selectors for which the private key is available or can be cracked.

Historically, 512 bit RSA was somewhat common, and old selectors don't always get removed.

  2.5.6. Hiring
  The "Hiring" field is used for linking to the vendor's security-related job  positions. If this field indicates a web URI, then it MUST begin with "https://"  (as per Section 2.7.2 of [RFC7230]).

Hey, I just found a new way to job hunt!

>If this field indicates a web URI, then it MUST begin with "https://"

Or what? What is the point of even specifying this? It's not like any human or bot is going to ignore the link if it starts with http://

I would be very dubious of applying to a security position with any company where the link started http://...

Why? They obviously need new expertise.

Bricklayers don't avoid un-built houses.

Sure, if you're planning on applying to a powerful enough position that you'd be able to effect significant change.

But for most jobs, where you aren't going to be able to affect massive change, you'll want the security culture not to bad/nonexistent.

If it is a public job description why must it be https? Baseless criticism might tell more about yourself than about them.

Because you care about privacy and other people knowing you're looking at the job postings?

Because you don't want a man in the middle modifying the job ad to say "must be 7 feet tall to apply"?

And finally because security should be the default unless there is a good reason to do it some other way. It's a bit like having an unpainted car because you're going to drive it in dry places where it won't rust... Unless there is a benefit to an unpainted car, most people take the painted car...

An unsecure http GET could be modified and redirect the interested person to a fake site, even if the original target would do nothing but redirect to its https-variant.

It does make sense.

I'm convinced the people commenting on this article are just contrarians.

"How could you possibly have standards" isn't a very interesting conversation yet here we are having it at scale.

>An unsecure http GET could be modified and redirect the interested person to a fake site

You don't have a threat model, do you?

"Beware of the leopard"

If you want to claim that you are compliant (perhaps it's a tick mark somewhere), then you need to follow the rules.

Btw, if you want to start with "http://" just declare it to be not-a-web URI. Eg say it's a git URI.

Section 5.7 of the same RFC actually lays out the reasoning and security considerations for mandating https.

I'm not sure where "web URI" is defined, but I am pretty sure that a Git URI uses "git://" and Git-via-http is still a "web URI" method.

There are quite many browser-supported protocols which are not http or https, which can be used also for malicious purposes.

HTTPS is probably the only protocol which is guaranteed to show content from the claimed source.

Not FTPS or SFTP?

Funnily these protocols are not supported by the Chromium or Firefox anymore.

I am not sure why it's relevant whether methods are supported by GUI browsers at all (please refer to URIs by method, not "protocol"); because the security.txt is likely to be parsed automatically (since it is, of course, not HTML) and indeed, "tel:" and "mailto:" are both somewhat apt methods to be invoked by a company who's hiring/receiving reports, and doesn't want/need a website for it.

So yeah, it is important that this part of the RFC specify a difference between "web" and "non-web" URIs, because the authors of security.txt are free to use any URI method that makes sense.

SFTP (sort-of-FTP over SSH) was never browser supported afaik. I'm not sure about FTPS (FTP over SSL/TLS), did browsers support it when they supported regular FTP?

Interesting implication that the field can contain a non-web URI. I just imagine seeing a `file://` URI and the application procedure is to somehow get your CV onto their server.

That is one way to show your commitment to “encourage career growth” I guess?

Assuming someone who works at the company would have easier access to someone who has access to the server in question…

As a recent college grad, I was struggling to find job interviews this year and decided to be a bit creative. I scoured Google for humans.txt files containing job openings, and discovered a couple of relevant ones, such as Expensify's (https://www.expensify.com/humans.txt) and my favorite from Tumblr (https://www.tumblr.com/humans.txt). Expensify even got back to me for an interview!

My hope is that one of these days, I will stumble upon a company that hides secret job openings in their .plan files - accessible through the finger protocol (https://en.wikipedia.org/wiki/Finger_(protocol)) :)

See: "finger @lsc.mit.edu" and "finger seattle@graph.no" for some examples.

Sorry but I don't want anyone fingering my server thank you very much.

It's your servers fault for dressing in vulnerable clothing.

Keep in mind this is only mandatory for government websites. That's a pretty low bar. If I worked for the government, or even a company that had one clear way to contact security, I would love this. I honestly have no fucking idea how to directly contact security most of the time and that's insane because I actually want to help them.

I don't care if they receive spam, I just want them to tell me how to contact them. Give me a captcha form, a phone number, an AOL Instant Messenger handle, I don't care.

How about a fax number?

welcome to Germany

or Japan

"Dutch government websites must comply with the security.txt standard from 25 May. This is announced by the Digital Trust Center of the National Government."

Somewhat ironically:

https://www.digitaltrustcenter.nl/security.txt

The website of the Digital Trust Center returns 404

You are looking in the wrong place. https://securitytxt.org/ proposes to create a text file called security.txt under the .well-known directory of your project.

So, the URL becomes: https://www.digitaltrustcenter.nl/.well-known/security.txt

This returns a 200 (via 302).

Ironically, that information is apparently not well known.

I do get why they standardized it that way, but boy is it ugly.

It's "well known" if you've manually set up SSL certs for a site using certbot. But yea I agree it's a weird choice to put it there instead of the same place as humans.txt, robots.txt and etc.

Iirc “they” decided that all new standards for “specific URLs you may want to serve for a particular purpose” will be under /.well-known. Robots is grandfathered because it’s super old and established and thus crazy to move. There won’t be anymore “at the root” standards.

Au contraire, it's the other way around. It makes more sense to put favicon.ico, robots.txt and humans.txt in .well-known, but that's life, these files are legacy. (shrugs)

I wasn't going to add one but I might actually put one in my root just out of spite.

Devs need to stop demanding other devs jump through pointless hoops.

On linux, there is a ~/.config directory, yet devs who think they know everything still pointlessly litter my home directory...

Don't litter your web root either ;)

Wouldn't it be beveiliging.txt?

Us Dutchies, in contrast to the French, don't come up with new words. Our language is Englishifying more and more.

We've always been strongly influenced by our big three neighbors (UK, France and Germany). I remember reading somewhere that before WW2 France was our biggest "cultural influencer" (for example, we spelled helicopter "hélicoptère", until the Canadians liberated us). It's probably not surprising that WW2 made German less popular, and the Anglosphere more popular afterwards.

Cesses de téléverser des billevesées sur hackernews, Hollandais

Notre langage est parfait

> sur hackernews

"nouvelles de pirates", sûrement? :)

GAZETTE du BIDOUILLEUR

Excuse moi, je suis een baquette.

I traveled in southern France for a bit and it seems to me like it could be a Paris/Quebecois thing because I found a "STOP" (no "ARRÊT" on it anywhere) sign at an intersection in about as rural an area you can get. Granted, sample size is small, but there do seem to be gradients even inside France.

That's because France like many other countries, but not Canada, signed an international treaty that standardizes road signs: https://en.wikipedia.org/wiki/Vienna_Convention_on_Road_Sign... That makes it a bit easier to drive safely across countries without reading all local languages.

Edit: Huh, apparently "stop" or the equivalent in the local language are allowed by the treaty. Didn't know that. https://en.wikipedia.org/wiki/Stop_sign

> apparently "stop" or the equivalent in the local language are allowed by the tr

Yes, but this is the only octagonal sign in the treaty, I suppose specifically so it's meaning could be inhered without knowing local language

How about beveiliging.tkst?

https://www.digid.nl/security.txt

redirects to:

https://www.ncsc.nl/.well-known/security.txt

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    # Domeinen van de Rijksoverheid kunnen met een 302 redirect verwijzen naar
    # het centrale bestand op https://www.ncsc.nl/.well-known/security.txt
    # omdat het NCSC het centrale meldpunt is voor kwetsbaarheden en incidenten
    # voor de Rijksoverheid.
    #
    # Dutch central government domains can redirect to the central file located
    # at https://www.ncsc.nl/.well-known/security.txt with a 302 redirect,
    # because NCSC-NL is the central point of contact for vulnerabilities and
    # incidents for the Dutch central government.
    
    Expires: 2024-01-31T22:59:00.000Z
    Canonical: https://www.ncsc.nl/.well-known/security.txt
    
    Policy: https://www.ncsc.nl/contact/kwetsbaarheid-melden
    Policy: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
    
    Contact: https://www.ncsc.nl/contact/kwetsbaarheid-melden
    Contact: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
    Contact: mailto:security@ncsc.nl
    Encryption: https://www.ncsc.nl/contact/pgp-key
    Preferred-Languages: nl, en
    
    Acknowledgments: https://www.ncsc.nl/wall-of-fame
    Hiring: https://www.werkenvoornederland.nl
    
    -----BEGIN PGP SIGNATURE-----
    Version: Encryption Desktop 10.4.2 (Build 1298)
    Charset: utf-8
    
    wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6v
    YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG0pA
    B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJvhxq8
    mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOoWvS6SRX
    KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuazc5iynhhih
    +ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC
    2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ
    wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq
    lNVMWzOncidAWM0nXcuYTjZagRAagthF
    =yC4A
    -----END PGP SIGNATURE-----
 Version: Encryption Desktop 10.4.2 (Build 1298)
 Charset: utf-8

wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6v YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG0pA B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJvhxq8 mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOoWvS6SRX KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuazc5iynhhih +ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC 2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq lNVMWzOncidAWM0nXcuYTjZagRAagthF =yC4A -----END PGP SIGNATURE-----

Really cool. I’ve done responsible disclosure in the past and finding someone who’ll listen is probably the hardest part of it

20 years ago emailing webmaster@, hostmaster@, abuse@ went direct to a tech person. I think these days it's also redirected to customer service.

IME sometimes you're lucky and it goes to a product manager, but then it is often put in the backlog with 100s other tasks.

Or just rejected—even postmaster@ which is mandated in RFC 5321.

Oh for sure, I'm sitting on a subdomain takeover at a pretty large company, I tried looking for an appropriate email or place to report it, found none so I just went the support route without any luck, just said they "will share it with the appropriate team", I've had control for over 2 months now.

I’m working on a simple website generator for developers and content creators.

I’ve already included everything a user would want for a complete website, including a robots.txt, sitemaps, perfect Lighthouse seo score, rich snippets, and a ton of other stuff.

Should I consider adding an auto generated security.txt file along side the robots.txt file for users?

Do you’all think a security.txt file is something users would want in 2023? Or would it look stupid and confusing?

https://github.com/elegantframework/elegant-cli

IMO, including those generated .txt files is a small[ish] feat that's important to those that are looking for it, and benign to those that don't need it or know what it is.

I suspect most users who use a site generator would be happy with more "automagic"—especially if it were 1. easy to config or turn off and 2. addressing important things like security-related contact info, or how a web-scraping bot should respect your domain.

Also: "simple" generators often veer into "complicated" territory by adding crap features. Elegant appears to lack crap features; IMO, adding *.txt would not complicate or confuse.

Hey thank you for the kind words!! No crap features here :)

We have started with a basic clean foundation, and are now in the process of building up all the essential features an app owner would want, and none of the crap they wouldn't lol.

I appreciate your feedback!

I have opened an RFC and will be pushing this idea through the feature pipeline ASAP: https://github.com/orgs/elegantframework/discussions/55

I got a few upvotes so far, but no comments! Lol

I may put out a few feelers, and put this topic up for a RFC and discussion on GitHub.

It seems like an interesting new little web thing, and is super easy to implement.

I just share the same concerns as others have mentioned with bots and spammers misusing this file.

Never heard about security txt files until now, but it makes a lot of sense!

Regulations are a hit or miss (e.g the cookie notification rules have some good parts but I wonder if there isn't any room for improvement in the current "visiting a website for 10 seconds and clicking whatever the big button is so that I see the content in interested in" status quo.

This one is not obtrusive, easy to implement (though only developers care about this part) and solves the problem.

The government making rules for its own subdivisions is different from those other regulations that constrain what private third parties can do.

The linked article explicitly mentions that they _hope_ private companies will adopt this standard; but there's no mention of any regulatory requirement on them.

Don’t set a cookie and you don’t need a cookie banner.

Websites choose to display that banner, they don’t have to.

Heard of it, but I’m still wondering why every RFC looks like it’s from 1998. We work with structured data all the time.

Then I remembered the armistice between yaml and toml and how I’m still confused about why the python community was torn asunder.

(lol. One looked like python to devs on mac/linux, and one looked like python to windows users who used INI a lot. Only a true scotsman uses plaintext, HTTP-style)

There’s a lot of history involved, and a difference between authoring and publication formats. It’s only comparatively recently (2016–2019, can’t remember exactly and can’t be bothered looking it up) that they stopped having the canonical form of the published document being monospace plain text with fixed pagination. Now, it’s markup, and so it can readily be presented in quite different ways. Observe this security.txt RFC 9116 formatted in two different ways:

https://datatracker.ietf.org/doc/html/rfc9116

https://www.rfc-editor.org/rfc/rfc9116.html

I checked the top 20 most used websites in Germany (with .de), and number 20 on the list is the first to have it: https://www.focus.de/security.txt

Most used webpages: https://www.similarweb.com/top-websites/germany/

I think Google suggested a path that was [URL]/.well-known/security.txt

Perhaps the sites have something on there.

Facebook have the security.txt at root: https://facebook.com/security.txt

Both Facebook and Apple also use [URL]/.well-known/security.txt

The contact on Facebook don't work: https://www.facebook.com/whitehat/report/

Should the title be “security.txt” instead of “Security.txt”?

Might be HN's auto-capitalization behavior when submitting.

security.txt discussed on HN:

2017: https://news.ycombinator.com/item?id=15416198 (145 comments)

2019: https://news.ycombinator.com/item?id=19151213 (55 comments)

2021: https://news.ycombinator.com/item?id=26455493 (167 comments)

I've just checked the UK's GDS advice and they have it as a "should": https://gds-way.cloudapps.digital/manuals/security-overview-...

They have more information at https://gds-way.cloudapps.digital/standards/vulnerability-di... where they strengthen the advice by saving:

  As per the current policy, we only accept reports from services that have a security.txt file pointing to the security policy.

> As per the current policy, we only accept reports from services that have a security.txt file pointing to the security policy.

So if their security.txt doesn't point to a service someone finds an issue with they won't respond?

Or they will respond by slamming down your door at 6AM :D

I take it as a way to say "don't even think of touching the services that don't have the security.txt file".

I think it means "our team isn't responsible for services without a security.txt, so don't contact us about it"

>I've just checked the UK's GDS advice and they have it as a "should":

Without forgetting that a UK 'should', is considerably different to a US 'should'.

.nl? - I'll let you guys decide.

Whatever happened to just having the standard "abuse@domain.name" email address?

The formal news release on this from the Dutch Standardization Forum can be found here: https://forumstandaardisatie.nl/nieuws/securitytxt-mandatory...

Note that you can test if a website has valid security.txt with the Internet.nl test tool: https://en.internet.nl/article/securitytxt-test-toegevoegd/

This is a win for GPG. Some, like the current PyPI maintainers, want to throw it out with no replacement. That's a terrible idea. And I don't see why it needs to be replaced completely.

https://www.amsterdam.nl/security.txt returns

---

Contact: https://www.amsterdam.nl/privacy/informatiebeveiliging-gemee...

Expires: 2024-02-01T10:00:00.000Z

Acknowledgments: https://www.informatiebeveiligingsdienst.nl/?s=hall+of+fame

Preferred-Languages: en,nl

---

rfc9116

2.5.1. Acknowledgments

The "Acknowledgments" field indicates a link to a page where security researchers are recognized for their reports. The page being referenced should list security researchers that reported security vulnerabilities and collaborated to remediate them. Organizations should be careful to limit the vulnerability information being published in order to prevent future attacks.

If this field indicates a web URI, then it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]).

Really appreciated this article - it's high time the Dutch government websites took steps like these towards strengthening their security! Still, they could definitely do with a bit more user-friendly explanations, so everyone can understand the importance of initiatives like security.txt.

https://mijn.overheid.nl/security.txt

404

but this one does exist https://www.ncsc.nl/.well-known/security.txt

Your first link is incorrect, it should be:

https://mijn.overheid.nl/.well-known/security.txt

which redirects to the second one.

Unless there's a way to mandate that the security team's contacts listed in security.txt actually respond in a timely manner to security-related messages that are sent to them, then I have a nagging feeling that:

* well-run organizations won't benefit from doing this, since their security teams were already easy to reach

and

* poorly-run organizations won't become any better by doing this, because one text file doesn't fix a broken org

1. Find a vulnerability

2. Contact the website maintainer to report it

3. Get swatted, harrassed by cops, sued, and jailed over it.

No thank.

Seems like a vector for phishing / social engineering and scammers / advertisers

Quick, find every site with a security.txt and report it /s

Isn't this what Whois is for ?

I hope other countries follow!

This measure is useful, but only if there are people answering the phone/email/etc that understand how to deal with the report - ie. security folks. In many places, they will just add the contact of some administrative assistant that has no concept of security and no options to deal with the report.

I agree, but probably still better than nothing?

Well most domain names have an abuse email address attached. I emailed a few that belonged to (presumably) compromised hosts sending spam and had no reply and no change in spam volumes. These types of measures are only useful if acted upon.

Similar experience here. Years ago I got emails from Mozilla for a few days in a row about failed login attempts to my account from a certain IP. I did a WHOIS on that and I obtained that it belonged to Fastweb, it was likely some household's dynamic IP. I emailed the listed Fastweb's abuse email address a couple of times, but never got any reply. The login attempts stopped, but I would say probably because whoever was doing it figured out they weren't able to guess my password, not because Fastweb actually did something about it.

Reply on news.ycombinator.com