[HN Gopher] Security.txt
___________________________________________________________________
Security.txt
Author : tosh
Score : 512 points
Date : 2021-03-14 14:00 UTC (8 hours ago)
(HTM) web link (securitytxt.org)
(TXT) w3m dump (securitytxt.org)
| coolreader18 wrote:
| A couple of websites/companies that have implemented this (just
| from checking ones I could think of):
|
| https://www.google.com/.well-known/security.txt
|
| https://www.cloudflare.com/.well-known/security.txt
|
| https://www.reddit.com/.well-known/security.txt
|
| https://github.com/.well-known/security.txt
| djcapelis wrote:
| The beautiful part of these is they show exactly what happens
| with these types of files, in that only one of them implements
| the spec as linked.
|
| (Expires isn't optional in the proposal on the website.)
| politelemon wrote:
| Their own security.txt also fails to do this
|
| https://securitytxt.org/.well-known/security.txt
|
| > # If you would like to report a security issue
|
| > # you may report it to us on HackerOne.
|
| > Contact: https://hackerone.com/ed
|
| > Encryption: https://keybase.pub/edoverflow/pgp_key.asc
|
| > Acknowledgements: https://hackerone.com/ed/thanks
| nwcs wrote:
| This was fixed: https://securitytxt.org/.well-
| known/security.txt
| n_u_l_l wrote:
| Expires was optional until draft 10 (August 2020)
| enw wrote:
| In fact I think _requiring_ an expiry date is a huge negative
| of the spec and will likely hinder adoption.
|
| An expiry date brings along with it _yet another_ maintenance
| burden for questionable benefit.
| ylyn wrote:
| Well, the spec only recommends that the date be no further
| than a year into the future.
|
| So if you really don't want the burden, just set a date in
| the year 9999 or something.
| waheoo wrote:
| Forcing work arounds in implementations so your spec is
| simpler is the epitome of why standards and specs fail so
| much.
|
| Design is hard. Good design makes implementation simple.
| jensenbox wrote:
| It would be way better to not have to "game" the value
| there if it is going to be garbage data.
| jensenbox wrote:
| I was literally going to craft a file and plop it on my site
| until I hit the "required expiration". I understand why it is
| there but think it should be optional. I think a better idea
| would be to steal from DNS and use TTL and serial numbers
| (maybe just standard http last-modified is enough?) - the
| point is "this stuff might be stale, reprocess it".
|
| The last thing I need is one more thing to have to remember
| and update.
|
| By the looks of it, a few others feel it is non-critical and
| have just skipped it too.
| mixedCase wrote:
| What a beautiful world we would be in if RFCs were required
| to include some sort of test suites wherever possible.
| aaronmdjones wrote:
| It should be noted that this is not yet an RFC, so
| compliance with it cannot be tested against an RFC.
| not_knuth wrote:
| Your comment made me think about using Google Search in a more
| alternative way to figure out who is hiring at a glance:
|
| https://www.google.com/search?q=hiring+well+known+security+f...
|
| Edit: If one is not up for the 2min it takes to parse some
| publicly available list.
| achillean wrote:
| This is already used by quite a few organizations/ websites:
|
| https://beta.shodan.io/search/report?query=http.securitytxt%...
|
| We've been indexing it for a while now and we haven't seen the
| number of websites that support it change significantly. It would
| make notifying organizations easier if this was a more widely-
| adopted standard. This is how it looks like when you pull an IP
| that has a service with that file:
|
| https://beta.shodan.io/host/5.28.193.120
| mrkramer wrote:
| Funny enough I was thinking about this not long time ago. I have
| a business idea which would utilize a concept like this.
| aasasd wrote:
| One aspect that is not reflected in this format is that the
| site/company might have a specific routine for reporting vulns.
| When I happened to write to Node (iirc) about some potential
| problem, the mail was just redirected to HackerOne, converted to
| some kind of a draft, and I got an automatic response saying I
| need to create an account there. In true marginal-nerd fashion, I
| have some opinions on which of my email addresses go where, so
| the account remains uncreated and the problem unreported by me.
| And Node didn't specify anywhere that this reporting works
| through HackerOne.
|
| (I also realize that this comment is probably not the right place
| to complain about the format, but eh.)
| aaronmdjones wrote:
| This is what the Policy: key in the format is for.
| aasasd wrote:
| You're right, that would work.
|
| Though the UX designer in me thinks that if the policy is
| important, it would be better to put in up on a webpage and
| slap that into the 'contact' field--as a neighbor comment
| suggests. At least when the whole process turns out to
| sidestep email completely.
| sedatk wrote:
| You can put a URL on the contact field.
| aasasd wrote:
| Ah! Indeed, I missed that alternative.
| Y_Y wrote:
| I'd have responded the same way.
|
| I'm not creating an account just to do someone else a favour.
|
| I will send an email and that's it. If you don't have an email
| address then you're not getting a message from me.
|
| It's disappointing how frequently this comes up.
| yarcob wrote:
| Yeah, worst part is when some support engineer asks you to
| please post the bug to a bug tracker, but the bug tracker
| requires an account, and when you try to sign up they make
| you wait for someone to review your account, and at some
| point you wonder if these people ever get a single bug report
| from a customer.
| [deleted]
| johnghanks wrote:
| https://securitytxt.org/security.txt
| _wldu wrote:
| A survey of security.txt - https://www.go350.com/posts/a-survey-
| of-security-dot-txt/
| coretx wrote:
| The language used in this draft is way to political and not
| technical/objective enough - herefore i think it causes more
| security risks than it resolves.
|
| Example: from line #1 "proper channels" - This is subjective as
| hell.
| a-dub wrote:
| isn't this what whois is for?
|
| barring that, (not much space for public keys and preference
| flags i guess), how about DNS TXT records.
|
| just some file on the root of the webserver seems a security
| issue itself. typically less people have keys to DNS. also, rare
| today, but not all domains have webservers.
| jagger27 wrote:
| In my experience WHOIS is basically useless now. All of my
| domains are registered through a privacy service and every time
| I've gone to check some sketchy domain's WHOIS out in recent
| memory I've found the same thing.
| a-dub wrote:
| sure, what about TXT records then?
|
| seems dangerous that anyone who can modify the root of a
| webserver content can impersonate security contacts/pubkeys.
| nwcs wrote:
| (One of the authors here)
|
| Make sure you read through the actual latest draft (especially
| section 6): https://tools.ietf.org/html/draft-foudil-
| securitytxt-11
|
| Also, we are in the end stages of the IETF approval process so
| this should be official later this year (if all goes well):
| https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
| geekone wrote:
| why is there no expires field on https://securitytxt.org/.well-
| known/security.txt
| Old_Thrashbarg wrote:
| Strangely, the draft just shows up as an empty page for me in
| Firefox, but Chromium works fine.
| dexterdog wrote:
| Yes, it's throwing a 404 for me on firefox as well.
| aembleton wrote:
| Same here, but the it started working once I opened Developer
| Tools and refreshed the page.
| nocman wrote:
| It did that for me at first, but it was due to my impatience.
|
| I tried again and waited, and after 10 or 15 seconds, the
| page finally loaded.
| pmh wrote:
| It's likely some kind of caching issue. tools.ietf.org at
| 4.31.198.62 responds with the draft, but 64.170.98.42 404s
| jwilk wrote:
| This one works for me:
|
| https://datatracker.ietf.org/doc/html/draft-foudil-
| securityt...
| ddevault wrote:
| Why not just put the PEM encoded key straight into this file
| instead of putting it at a separate URL?
| pseudoramble wrote:
| Seems like a reasonably good idea. More of a question about RFC's
| than the spec itself. I noticed while reading the RFC it mentions
| this:
|
| > By convention, the file is named "security.txt".
|
| Isn't the point of the RFC so that it wouldn't be by convention
| anymore? Or are they saying the idea for the name was from prior
| conventions? Or maybe I'm just reading into it too much and it
| doesn't really matter.
| anamexis wrote:
| I think the latter - they are saying the idea for the name was
| from prior conventions. Section 4 spells it out explicitly:
|
| > For web-based services, organizations MUST place the
| security.txt file under the "/.well-known/" path;
| willeh wrote:
| I agree, it definitely seems that the phrasing there needs
| work. Overall I would say most RFCs are well substandard
| especially when compared to ISO standards which tend to be
| extremely precise. That being said, interoperability within
| tech is amazing so perhaps there is something to be said about
| the idea of loose standards and working code after all.
| jcims wrote:
| Seems like there would be a natural tie-in with DNS to publish a
| pgp key to authenticate the txt file (per the advice to validate
| the key)
| Retr0spectrum wrote:
| Seems a bit redundant, if the page is being served over HTTPS,
| which ultimately relies on DNS records.
|
| The advantage of PGP is that it can be verified entirely out-
| of-band, and distributed widely.
| vzaliva wrote:
| The date in stipid US standard (mm/dd/yyyy) will confuse the hell
| of the rest of the world. Please use not US-centric ISO date
| format: yyyy-mm-dd.
| mike_d wrote:
| Your browser is misconfigured. The site uses the YMD "standard"
| but your computer is configured with a locale that prefers US
| style for date inputs. <input type="date"
| placeholder="YYYY-MM-DD" class="input" required>
| omni wrote:
| This site is only using mm/dd/yyyy for the generator input, the
| standard itself is not. The actual format in the security.txt
| file looks like:
|
| Expires: Tue, 16 Mar 2021 05:09 -0400
|
| Maybe slow down, read the spec, and proofread your comment for
| obvious errors before trying to troll for no reason.
| codefined wrote:
| Has the generator been updated? For me (UK) it's localised to
| dd/mm/yyyy, as I would expect in my region.
|
| I like that the spec uses a universal and unambiguous format.
| I especially like that this generator is localised to my
| region though.
| BrandoElFollito wrote:
| No, as @madeofpalk mentioned in response to my comment, it
| is using the standard date input. What you actually see
| depends on the locale of the browser (I see mm/dd/yyy in
| Chrome set to US English, and dd/mm/yyyy on FF set to
| French)
| brimstedt wrote:
| I still think iso standard would be better:
| https://github.com/securitytxt/securitytxt.org/issues/72
| BrandoElFollito wrote:
| > This site is only using mm/dd/yyyy for the generator input
|
| If this is intended to be some kind of standard, it should
| follow other standards. I understand that this is "only" in
| the generator, but why even there?
| madeofpalk wrote:
| It's just using the standard date input. Formatting of the
| input UI will depend on browser, OS, and locale of the
| users device.
| BrandoElFollito wrote:
| Ahhhh! Thanks for the update - I stand corrected.
|
| I am French and my Chrome is set to US English. I just
| opened a FF session, switched to French and the input is
| dd/mm/yyyy.
| goatsi wrote:
| The last time this came up on HN it got quite a negative review
| from someone who had tried it on several sites:
| https://news.ycombinator.com/item?id=19152145
|
| It apparently attracted automated scanners and the signal to
| noise ratio was atrocious.
| aasasd wrote:
| People here dislike HackerOne, but afaiu it solves this exact
| problem. It's the first line of 'support' for security
| reporters.
|
| The fact that the industry currently needs this kind of
| solution is surreally comedic. Basically, it would make actual
| sense to require people to pay ten bucks when posting a report
| --if they think the report is reasonable and that they would
| get paid for it.
| kjrose wrote:
| This would be my concern. It seems like a really good tool to
| attract the attention of bad actors.
| __throwawy9 wrote:
| I think it's good that they're trying to get away from the one-
| off weird stuff like CSP being made and overloading responses
| for HTTP requests with headers, metadata in the response, etc.
| and just suggesting a file request.
|
| But is the best thing really have multiple files that you just
| have to know about like robots.txt, security.txt, favicon.ico,
| ... or can we just have some request made to each host in a
| generic protocol which we could call HDP (host description
| protocol) that it can respond with information about itself in
| a dynamic or simple way, and just be done with it?
| nicbou wrote:
| I'm not sure I buy into the idea, but it couldn't have been sold
| any better. That security.txt generator is such a great way to
| get people on board. The whole website is really good at
| explaining the project.
| IgorPartola wrote:
| It's cute but it generates a five line plain text file. I would
| argue that a better way to sell the idea would be to create an
| Apache and nginx module so you could specify this stuff from
| those config files. It would make adoption seem easier to more
| people.
| danaris wrote:
| A lot of people have web hosting packages that don't give
| them direct access to the webserver configuration, but do let
| them upload arbitrary text files to their webroot.
| mjthompson wrote:
| Serving a 'text file' from a web server module seems to
| overcomplicate things in my view.
|
| More code || complexity == greater likelihood of bugs
| (including security bugs).
|
| As ironic as a security bug in a security.txt serving module
| would be, it's probably best we avoid that possibility and
| let the ordinary, highly scrutinised file serving code handle
| it instead.
| coolreader18 wrote:
| I think the text file generation is great - it is a
| standardized "syntax", so being able to just fill out your
| info in a webpage and getting the .txt to upload to a server
| (instead of having to "learn" the couple of keys to use for
| your values) really does make it painless.
| dfilppi wrote:
| The policy link is broken
| [deleted]
| hn_throwaway_99 wrote:
| IMO this totally solves the wrong problem. It's not really so
| much about "who do I contact if I find a security problem on a
| website", it's more about the problem on the other side "How do I
| separate the spam and low quality bug reports from actual
| defects, especially if I have a bug bounty program that attracts
| low quality bug reports."
|
| I think what is needed more is a community-managed "reputation
| score" for security researchers that could be used to indicate
| who has submitted high quality defects in the past. I shit on
| pie-in-the-sky blockchain schemes all the time, but this actually
| seems like one where I could imagine it being useful, i.e like
| this:
|
| 1. A site owner publishes their security team's public key in a
| well known location, similar to what is described in the
| security.txt proposal
|
| 2. When a user submits a bug report to some site that the owner
| seems is a bug, the user can sign something on the blockchain
| that states "User X found a [high,medium,low] defect" on our
| site.
|
| 3. Then, when a user wants to submit a defect to another site,
| they could show their past history of high quality bug
| submissions to past sites, and those submissions could even be
| scored based on some value of the site owner (e.g. finding a high
| impact defect on Apple would result in a high "reputation
| score.")
| geek_at wrote:
| > It's not really so much about "who do I contact if I find a
| security problem on a website
|
| Cannot confirm. I bought a windshield for my '01 Ford Focus and
| found a major security bug on their site [1] (they linked a JS
| file from a non-existant domain)
|
| I talked to CERT, the clerks at the store, tried to contact the
| owner on linkedin; heck it was even published in one of the
| largest newspapers of my country but never got anyone who
| understood the problem or cared.
|
| In the end the bug was fixed because I wrote them on facebook
| and the kid who's job it was to manage their facebook site was
| also the web admin
|
| [1] https://blog.haschek.at/2019/threat-vector-legacy-static-
| web...
| Kwpolska wrote:
| You don't need a blockchain for that. The thing you're
| describing is basically Hackerone:
| https://hackerone.com/leaderboard
| EE84M3i wrote:
| > especially if I have a bug bounty program that attracts low
| quality bug reports
|
| IMO security.txt provides value for when you DON'T have a bug
| bounty program. If you don't already have a 'front door' for
| how to send you security information, you're not going to get
| it.
|
| Also, I would put some money on someone finding a show stopper
| bug like shellshock/heartbleed/deserialization-bug-of-the-
| week/etc and contacting folks from their security.txt in sync
| with their public release sometime within the next few years.
| tgsovlerkhgsel wrote:
| One is a problem for the reporter, the other is a problem for
| the recipient.
|
| As a reporter, if I can't find where to report it, you'll find
| out about your issue when someone forwards my blog post to you.
| If you ignore my e-mailed report because you don't want to
| spend the resources on it, e.g. because I haven't built a
| reputation score, same thing.
|
| Most importantly: If the only way to report a security issue is
| through a platform with a "community managed reputation score",
| I'm much more likely to ignore that platform and again, you'll
| find out about your vulnerability from a blog post.
|
| security.txt actually told me about a contact address for
| Cloudflare that isn't HackerOne. (HackerOne, in particular, is
| on my shitlist because they impose terms of service that deter
| disclosure unless the vendor agrees, and they don't let you
| publish through their platform if the vendor is unresponsive.
| If the only way to report to you is through HackerOne... see
| above.)
| bjeds wrote:
| I'd be a bit careful if I were you. Bug bounty programs are
| after all the exception rather than the rule - the security
| equivalent of open sourcing software - an active decision by
| the company to sign away normal rights and normal legal
| protection.
|
| If you find a vuln and publish it and the company does not
| have an explicit bug bounty program allowing such things, you
| may be sued or face other legal action.
|
| I know several security researchers who have been sued for
| hacking, in many countries (mostly across US and Europe),
| because they assumed they were doing a "good thing", whereas
| the law doesn't care - it only cares about what is legal or
| not legal. Apart from the hacking charges, the very nature of
| bug bounties means it's pretty easy for the lawyers to add a
| coercion/blackmailing charge as well, which makes it more
| serious.
| Daho0n wrote:
| "The law" doesn't sue anyone so the company is the one that
| "doesn't care". The law (if in a functional system) doesn't
| follow the letter of the law but the spirit of the law.
| Otherwise we wouldn't need a court but just a clerk or a
| low-level AI.
|
| There're only three categories IMO (besides black hat):
|
| 1) The researcher disclose a vulnerability the proper way
| and all's good
|
| 2) The "researcher" did something that could cause harm and
| were punished
|
| 3) The system is utterly broken
|
| I have seen all happen and the ones people are up in arms
| about have always been in category 2 or 3. Your last
| sentence about blackmail is in category 2 as demanding
| money for a proper disclosure from someone without a bug
| bounty program is the definition of blackmail.
| Y_Y wrote:
| For anyone else who was wondering what the legal
| definition of blackmail might look like, 18 U.S.C. SS
| 873:
|
| "Whoever, under a threat of informing, or as a
| consideration for not informing, against any violation of
| any law of the United States, demands or receives any
| money or other valuable thing, shall be fined under this
| title or imprisoned not more than one year, or both."
| [deleted]
| Sephr wrote:
| There are strong protections in the US regarding
| vulnerability disclosure due to freedom of speech. If you
| are able to run software that you own which doesn't have
| any anti-reverse-engineering ToS on your own computers, you
| are generally in the clear to publish knowledge of flaws
| that you find while inspecting the software on your
| computer.
|
| This doesn't mean that you won't get sued, but it does
| increase your likelihood of winning such lawsuits when you
| haven't committed any crimes during your security research
| & disclosure.
|
| You are not required to ever tell the affected parties at
| all, and afaik you are also free to stockpile and sell
| exploits as long as you only sell them domestically (IANAL
| & TINLA).
| bjeds wrote:
| That's true, but in my experience vulnerability
| researchers mostly focus on the online presence/product
| of internet-active companies (the FAANG:s of the world,
| and their smaller competitors - companies that could
| realistically be on HackerOne/BugCrowd without standing
| out like a sore thumb).
|
| If you've bought some software you install on your
| computer - like the good old days ( :) ), it's more fair
| game as you said.
| pavel_lishin wrote:
| > _I shit on pie-in-the-sky blockchain schemes all the time_
|
| And you're right to, because they're mostly nonsense.
|
| One of the issues with your proposal is that if I'm a security
| researcher, I now have to pay to maintain my reputation using
| cryptocurrency.
| dstroot wrote:
| I don't believe that paying for your reputation was what the
| poster meant. Blockchain can be used for basically "write
| once" non-alterable records that you can prove you "own"
| without any currency aspects. That is basic blockchain tech.
| However it would cost money to run the machines that managed
| the BC and people would not do that without an economic
| incentive so maybe you're right?
| pavel_lishin wrote:
| Right. If you want to put things on the blockchain, you
| need to pay for the privilege somehow - mining blocks,
| executing contracts on ethereum, etc.
| remram wrote:
| Also you are assuming that the recipients of those reports,
| the websites, would be truthful in their acknowledgement of
| issues and would not abuse their new power over researchers'
| reputations. Especially when each accepted bug leaves a
| permanent public record.
| pavel_lishin wrote:
| Right. Not to mention, what's to prevent an unscrupulous
| "researcher" from paying companies - or starting their own
| fake ones - to enter positive feedback, etc?
|
| Sorry to burst your bubble, hn_throwaway_99, but this is
| the same kind of nonsense idea that you typically scoff at.
| It offers no new benefits, while adding new problems.
| baby wrote:
| .txt file, uses markdown
|
| On a more serious note, all these sitemap and bot-friendly
| standards for webpages always tend to fail. Even RSS, which is
| probably the most important standard in this space, has issues
| getting more adoption.
| mtmail wrote:
| # marks a comment in the text file, not a headline
| OptionX wrote:
| I'm pretty sure the hash is meant to symbolize a comment, not a
| header.
| Areading314 wrote:
| Wasn't semantic web supposed to generalize the hosting of
| structured info? Seems like this is just a special case
| einpoklum wrote:
| Today I learned about .well-known/ :
|
| https://en.wikipedia.org/wiki/List_of_%2F.well-known%2F_serv...
|
| I remember such files used to go into the root of the website's
| hierarchy; I guess it's nice that now they're mostly bunched in a
| subfolder.
| dheera wrote:
| Why not just put this info into whois?
|
| Also, how do I know whether to believe the link to the encryption
| key? That stuff should be in the HTTPS certificate, not a text
| file. Just use the server's public key to encrypt communications
| to the website owners.
| Kwpolska wrote:
| Whois is not a good place for this data. Whois data is
| typically abused by spam bots (and most people don't look
| there), it can't be easily extended with security-specific info
| (a link to the encryption key? a link to the full security
| policy?), it works only for the registered domain (you can't
| have different whois for maps.google.com and mail.google.com),
| and some registries might have policies that make it difficult
| to fetch WHOIS data (eg. by blocking IPs of cloud providers, or
| by forcing you to go to a website to see full subscriber
| information).
| dheera wrote:
| > it can't be easily extended with security-specific info
|
| Just put a public key into the address field, for example.
| More abuse of field names is good because it will keep trip
| up the bots that use e.g. the address field as a spam mail
| address or pass it to data brokers.
|
| I'd love to see a data broker say "John Doe lives at ===
| BEGIN PGP KEY === 0xA3243ABC3F... Do you want to dox them?
| Yes/No" and more spam mailers waste their money attempting to
| send ad mailers to "=== BEGIN PGP KEY === ..."
| bombcar wrote:
| If security.txt takes off it will be abused by spam bots also
| megous wrote:
| I'm sure they'd be very excited if I sent them PGP encrypted
| email message using a public key extracted from some possibly
| stale public cert of their http server.
| upofadown wrote:
| This is all done over TLS connections, including the link to
| the encryption key. So the provenance is already at the
| certificate level. Using PGP means that this provenance can be
| increased past that level if required.
| dyeje wrote:
| How widely adopted is .well-known? I had never heard of it
| before.
| riffic wrote:
| it's defined in RFCs 5785 and 8615. not our fault you don't
| know .well-known
| kadoban wrote:
| Pretty common. Let's Encrypt uses it, few other things I've run
| across, Matrix homeservers, etc.
| throwaway29303 wrote:
| Ha. I see what you did there. But I'll take it literally and
| for others who aren't aware there's an IANA site describing all
| 'legal' and 'official' .well-known URIs[0].
|
| [0] - https://www.iana.org/assignments/well-known-uris/well-
| known-...
| eddieh wrote:
| So we have all of these implicit URIs:
| robots.txt humans.txt .well-known/security.txt
| favicon.ico ads.txt app-ads.txt
|
| Am I missing any?
|
| Part of me thinks that the root index.html should have link or
| meta tags for any and all of these. HTTP headers would also work.
| I get that robots.txt and favicon.ico are historical and
| humans.txt is cutesy, but this is getting kind of polluted.
| Perhaps I'm missing some obvious reason for why we're still doing
| the .txt thing?
| sedatk wrote:
| That's the purpose of .well-known going forward: prevent
| pollution and allow access without discovery.
| anticensor wrote:
| What about the alternative, hackers.txt?
| [deleted]
| bewuethr wrote:
| It looks like one is the evolution of the other:
| https://stackoverflow.com/a/56332115/3266847
| loloquwowndueo wrote:
| A top-level security.txt sounds like a better idea than hiding it
| under .well-known. I wouldn't want anyone without access to the
| web server's root to be telling me what the security policy is,
| anyway.
|
| Having it at top level makes it a sibling / analogous to
| robots.txt so there is some consistency to the pattern.
| [deleted]
| willeh wrote:
| `.well-known` is already used for validation for many things,
| perhaps most crucially acme-challenge which is used by
| LetsEncrypt to issue domain validation certificates.
| LetsEncrypt is trusted by all major browsers at this point so
| it seems that the consensus is that .well-known must be kept
| secure at any cost. So even if you disagree with `.well-known`
| it must de facto be kept in the inner-most ring of your
| security model.
| loloquwowndueo wrote:
| My point exactly - validation usually involves write
| permissions to put a challenge or something else as required
| by the protocol (ACME in your example). If I put the
| security.txt file there and certbot gets compromised, there
| goes my security policy. Putting security.txt up one level so
| only root (I.e. me) can update it allows me to keep .well-
| known writable by robots only.
| thaumaturgy wrote:
| Right, which is why putting this file under .well-known is a
| small inconvenience.
|
| It's increasingly common for server configurations to have a
| reverse proxy routing requests to internal containers or
| servers. Things like SSL renewals are often handled by the
| reverse proxy (because reasons [1]), so those requests don't
| get routed to the internal hosts by default.
|
| Site-specific stuff, like this file, probably belongs in the
| site's root directory.
|
| This is a bit bike-shedding though. It's only a small
| aggravation to work around.
|
| [1]: Because you want to automate as much of the
| configuration as possible, so when a new hostname is added to
| a container or internal server, an SSL certificate just
| magically happens for it. This requires changes to the
| reverse proxy's configuration, and that's not something you
| want the internal containers doing, so it falls to the proxy
| to handle these itself. Letting the containers handle their
| own SSL setup means you have to have some kind of privileged
| communications channel from the container up to the reverse
| proxy, which is undesirable.
| remram wrote:
| The problem is when there starts to be many "site-specific
| stuff". It's easy to remember not to route .well-known to
| user-generated content in your app. It's less easy to
| remember a list of endpoints, like robots.txt,
| security.txt, and so on. And what when that list grows?
| What if you already have a user called "security.txt" (or
| whatever the next one is)? This is why a .well-known prefix
| is valuable.
| kortex wrote:
| Right. This seems like a good pattern to have. Much like
| app/framework specific config, I much prefer to have
| everything under ~/.local/ than a myriad of ~/.foo
| dotfiles. It's only one endpoint to route, and you don't
| need to change configs each time you add some new static
| file.
|
| IMHO, index.html and favicon should be the only files
| living at top level, and I guess robots.txt since that's
| a de facto standard (and soon to be actual standard iirc)
| styfle wrote:
| It would be great to move robots.txt to .well-known
| instead.
|
| Same with favicons, although you can specify an arbitrary
| path to most favicons using index.html
| sodality2 wrote:
| Dammit I was hoping this would include password requirements. I
| remember reading about a similar proposal on HN before.
|
| The way I saw it described was a field for password security
| requirements, a field for an API url to let you change a
| password, etc. This would allow password managers to easily and
| simply change account passwords en masse. I suppose there are
| security risks as well, so maybe an email going out saying "an
| automated password change request was made, these often come from
| your password manager but only if you initiated it. If you want
| to approve this change, click here"
| mtmail wrote:
| There's /.well-known/change-password to redirect to the feature
| on your website to help password managers.
| https://web.dev/change-password-url/
| Cloudef wrote:
| >A link to a web page where you say thank you to security
| researchers who have helped you. Remember to include "https://".
|
| This sounds like mafia
| cmsefton wrote:
| Not sure if there's something new here, but this has popped up
| before on HN.
|
| https://news.ycombinator.com/item?id=19151213 (2019)
| https://news.ycombinator.com/item?id=15416198 (2017)
| tequila_shot wrote:
| The link: https://tools.ietf.org/html/draft-foudil-securitytxt
| returns 404.
| eatbitseveryday wrote:
| Doesn't for me.
| JdeBP wrote:
| That's because it is actually
| https://tools.ietf.org/html/draft-foudil-securitytxt-10 . IETF
| drafts have version numbers.
|
| * https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
| birdyrooster wrote:
| security.txt gets its naming from robots.txt?
| tempestn wrote:
| .txt is a file extension designating a plain text file. But
| yes, new well-known files of this sort intended to be included
| on websites, like humans.txt and now security.txt, do follow
| the naming convention of robots.txt.
___________________________________________________________________
(page generated 2021-03-14 23:00 UTC)