Dev%2FAbout_Infrastructure.mw

{{Header}}
{{#seo:
|description=Development Notes / Design Documentation about {{project_name_long}} Infrastructure
}}
{{intro|
Development Notes / Design Documentation about {{project_name_short}} Infrastructure
}}
= Current Situation =
== Introduction ==
[[Privacy Policy Technical Details|{{project_name_short}}.org Site Security]]

This page talks about {{project_name_short}} online hosting and (non-existing) testing infrastructure.

== File Hosting ==
Hosted by mirror, downloadable using TLS.

== Testing infrastructure ==
* CI build environment required.
* Automated Test Suite <ref>
Port [https://tails.boum.org/contribute/release_process/test/automated_tests/ Tails Test Suite] or create a new one from scratch.
</ref> required.
* [[systemcheck]]

= backend =
== MediaWiki ==
=== MediaWiki advantages ===

* community contribution friendly - flagged revisions - usable way to allow anonymous users to edit and to let admins review changes before these go live
* sufficient protection from spam
* seo - plugins provide good OpenGraph meta tags and meta settings (description, images)
* wiki templates
* footnotes
* expand buttons
* footer
* mobile view
* mediawiki markup text file backups (but are not easily importable)
* [https://forums.whonix.org/t/short-and-detailed-buttons-in-the-wiki-html-help-wanted/1700 short and detailed buttons] (probably not unique to mediawiki)

=== MediaWiki disadvantages ===
* offline documentation
** non-ideal
** [[Offline Documentation]]
** https://forums.whonix.org/t/offline-documentation-discussion
* translations not solved
* data base is binary (mysql) (requires mysql data base)
** in other words: not flat file
** not easy "transparent" backups
** cannot rebuild from clean human readable source files

=== goals for new website ===
* flat file
* git based?
* prose.io ([https://prose.io/#adrelanos/vpn-firewall/edit/master/README.md example]) compatible?
* breadcrumbs navigation?
* javascript free?
* CMS free?
* bootstrap based?
* mobile friendly
* illustrative images
* quick page load times
* footer links (legal, imprint)!
* seo

== discourse forums ==
TODO: archival using httrack?

* cannot make complete backup - https://meta.discourse.org/t/how-to-backup-and-restore-a-whole-var-discourse-app-folder/152598
* backup restoration failing - https://meta.discourse.org/t/restore-problem-relation-theme-fields-does-not-exist/95500/7
* postgres database bugs - https://meta.discourse.org/t/restore-fails-could-not-create-unique-index/151380/20
* difficult to repair database - https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614
* no archival - https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614
* archival feature request #1 https://web.archive.org/web/20200805132135/https://meta.discourse.org/t/print-long-topic-to-pdf-redux-again/44639/62
* archival feature request #2 https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614/51
* feature request: [https://meta.discourse.org/t/option-to-use-flat-text-backing-files-instead-of-sql-postgres-backend/152787 Option to use flat/text backing files instead of SQL(Postgres) backend]

= Security =
See [[Trust#Trusting_the_{{project_name_short}}_Website]].

= OCSP =
{{Anchor|OSCP}}
OCSP is only relevant in case if a TLS certificate is ever revoked.

must staple needs to be activated:

* on web server [safe] [done]
* inside TLS certificate [can break connectivity] [will not be implemented]

resources:

* https://security.stackexchange.com/questions/151962/what-is-the-exact-difference-between-regular-ocsp-and-ocsp-stapling
* https://www.imperialviolet.org/2012/02/05/crlsets.html
* https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/
* https://scotthelme.co.uk/ocsp-must-staple/
* https://blog.cloudflare.com/high-reliability-ocsp-stapling/
* https://www.aaronpeters.nl/blog/ev-certificates-make-the-web-slow-and-unreliable/
* https://nooshu.com/blog/2020/01/26/the-impact-of-ssl-certificate-revocation-on-web-performance/
* https://unmitigatedrisk.com/?p=241
* https://web.archive.org/web/20220512065636/https://blog.crashed.org/nginx-stapling-busted/
* https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41115

nginx bugs:

* https://trac.nginx.org/nginx/ticket/812
* https://trac.nginx.org/nginx/ticket/1998
** <blockquote>The OCSP "must staple", however, is a completely different thing, and getting OCSP "must staple" to work with nginx might be tricky: you have to either ensure that OCSP responses are preloaded somehow, or have to use ssl_stapling_file and provide responses yourself. Avoid using OCSP "must staple" flag in certificates unless you are going to deal with this. Closing this as a duplicate of #812, which is about improving compatibility with "must staple" without using ssl_stapling_file.</blockquote>
* https://trac.nginx.org/nginx/ticket/1830
** <blockquote>Avoid using "must staple" in certificates unless you are going to provide OCSP responses yourself using the ssl_stapling_file directive.</blockquote>
** at Mozilla also pointing out that nginx bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1366100

postfix:

* OCSP won't be implemented in postfix: https://marc.info/?l=postfix-users&m=151119229905817

OCSP must-staple is "dead", long life CRLite.

* https://letsencrypt.org/docs/revoking/
* https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/
* https://scotthelme.co.uk/crlite-finally-a-fix-for-broken-revocation/
* https://scotthelme.co.uk/revocation-is-broken/
* https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
* https://letsencrypt.org/2022/09/07/new-life-for-crls.html
* CRLite is a browser and CA (certificate authority) feature. Not a server feature.

Info:

* OCSP - CA feature
* OCSP stapling - server feature
* OCSP must-staple - certificate feature
* checking OCSP (ask CA) or checking stapled OCSP - browser feature

Conclusion:

Due to,

* OCSP only relevant after a TLS certificate or CA has been compromised,
* many multiple years unfixed nginx bugs,
* high risk of broken connectivity,
* OCSP must-staple being unpopular,
* browsers ignoring OCSP / must-staple with softfail,

the following actions have been taken:

* OCSP stapling has been enabled server-side.
* OCSP must-staple has not been set in the TLS certificate.

= DANE TLSA =
* test websites:
** web: https://danetools.com/dane
* another website working example: https://dane.sys4.de/smtp/go6.si
* https://mytechiethoughts.com/linux/implementing-dane-with-certbot-using-lets-encrypt/
* what happen to these screenshots?
** https://www.dnssec-validator.cz/pages/screenshots.html
** https://www.dnssec-validator.cz/images/screenshots/firefox.png
** https://www.dnssec-validator.cz/images/screenshots/ie.png
** https://www.dnssec-validator.cz/images/screenshots/cr.png
** https://www.dnssec-validator.cz/images/settings/config.png
** Firefox saying: Verified by: Let's Encrypt
* not yet supported by SSL Labs https://github.com/ssllabs/ssllabs-scan/issues/118
* https://www.internetsociety.org/blog/2013/12/want-to-quickly-create-a-tlsa-record-for-dane-dnssec/
* https://www.cambus.net/creating-tlsa-records/
* letsencrypt vs DANE TLSA?
* https://webmasters.stackexchange.com/questions/129712/is-letsencrypt-compatible-with-dane-tlsa
* DANE TLSA standalone?
* DANE TLSA update required, useful when?
* https://github.com/FlippingBinary/lets-encrypt-tlsa
* https://threatpost.com/ssl-and-future-authenticity-041111/75125/
* https://www.youtube.com/watch?v=Z7Wl2FW2TcA
* https://forums.whonix.org/t/dane-tlsa-dns-based-authentication-of-named-entities-for-whonix-org/10218

quote https://mytechiethoughts.com/linux/implementing-dane-with-certbot-using-lets-encrypt/

<blockquote>
The problem with regular Let’s Encrypt certificates

As you know, Let’s Encrypt certificates renew every 90 days. This is not a problem in itself, however, the standard procedure is to generate a new private key with each renewal and, thus, an entirely new public key also. This will necessarily change the hashed key value that would appear in our TLSA record meaning that we would have to remember to update our DNS records on each renewal otherwise the wrong key will be specified and no one will trust our site/server/application! We need to tell Let’s Encrypt to re-use our private key so that the public key hash value does NOT change – that way our DNS record remains valid across certificate renewals.
</blockquote>

-> https://github.com/letsencrypt/boulder/issues/1882

-> https://www.internetsociety.org/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/

-> https://www.internetsociety.org/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

* https://dane.sys4.de/common_mistakes
* https://wiki.archlinux.org/index.php/DANE
* https://github.com/FlippingBinary/lets-encrypt-tlsa
* [https://archive.ph/bBFvh Moxie-SSL And The Future Of Authenticity]
* todo reading:
** https://sockpuppet.org/blog/2015/01/15/against-dnssec/
** https://thenextweb.com/news/libyas-clarifies-the-vb-ly-takedown-bit-ly-can-breathe-easy
** https://dev.gnupg.org/T4618

= drop-www vs yes-www =
== cookies ==
=== cookie isolation ===
Quote https://www.bjornjohansen.com/www-or-not

<blockquote>Cookies are passed down to subdomains</blockquote>

This might be a security issue.

* https://security.stackexchange.com/questions/267025/are-there-any-security-reasons-against-drop-www-using-example-com-instead-of
* https://www.invicti.com/blog/web-security/impact-www-subdomain-cookie-security/
* https://jacob.hoffman-andrews.com/README/why-you-need-a-www/
* https://web.archive.org/web/20140510024314/http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/
* https://stackoverflow.com/questions/4074027/is-it-possible-to-isolate-domain-ext-sub1-domain-ext-and-sub2-domain-ext-s-cook
* https://webmasters.stackexchange.com/questions/55790/setting-cookies-only-on-the-naked-domain
* https://security.stackexchange.com/questions/231735/cookie-domain-security
* https://stackoverflow.com/questions/13129947/is-there-a-way-to-control-which-urls-a-cookie-gets-sent-to
* If you login on github.com, you are also automatically login to gist.github.com.

Quote https://www.rfc-editor.org/rfc/rfc6265 (April 2011):

<blockquote>The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.  For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".</blockquote>

Quote https://www.ietf.org/rfc/rfc2109.txt (February 1997):

<blockquote>A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string.  (So, x.y.com domain-matches .y.com but not y.com.)</blockquote>

Maybe fixable by hostonly cookies.

Quote https://stackoverflow.com/questions/12387338/what-is-a-host-only-cookie

<blockquote>Host-only only protects example.com cookies from being read by bar.example.com.</blockquote>

* https://forums.whonix.org/t/mediawiki-cookie-https-onion-settings/16120
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_where_cookies_are_sent
* https://security.stackexchange.com/questions/33851/protecting-against-cross-subdomain-cookie-attacks
* https://secure-cookie.io/fundamental/sop/

=== cookie performance ===
Quote https://www.bjornjohansen.com/www-or-not

<blockquote>Unnecessary cookies hurts performance</blockquote>

== caching ==
https://www.section.io/blog/bare-domain-cookies/ paraphrased and summarized: If unrelated cookies for the apex domain name (example.com) are sent for subdomains (such as forums.example.com) then this is bad for caching.

== scaling ==
Quote https://docs.gandi.net/en/domain_names/faq/record_types/alias_record.html

<blockquote>
An ALIAS record will break DNSSEC on the bare domain (@), because @ A and @ AAAA responses will be missing the RRSIG records, which will break resolution on all resolvers.
</blockquote>

Quote https://docs.gandi.net/en/domain_names/faq/dns_records.html ('''bold''' added)

<blockquote>
A, AAAA, '''ALIAS (not yet supported with dnssec-enabled domains)''', CNAME, MX, NS, TXT, WKS, SRV, LOC, SPF, CAA, SSHFP, PTR, DNAME
</blockquote>

Quote https://help.heroku.com/NH44MODG/my-root-domain-isn-t-working-what-s-wrong

<blockquote>
Cloudflare - Note: Cloudflare use <code>CNAME Flattening</code>. This is the same thing as an <code>ALIAS</code> or <code>ANAME</code> record
</blockquote>

https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

== popular survey ==
Some of the highest traffic, most popular webstes such as google.com are still using the www subdomain.

{{CodeSelect|code=
scurl --silent --head https://google.com {{!}} grep -i location
}}

<pre>
Location: https://www.google.com/
</pre>

== SEO ==
https://seranking.com/blog/www-vs-non-www/

= Hide Server IP =
Separate server/IP for e-mail required since it cannot be hidden by CDN.

Quote https://support.cloudflare.com/hc/en-us/articles/115003687931-Warning-about-exposing-your-origin-IP-address-via-DNS-records

<pre>
To take advantage of Cloudflare’s performance and security benefits, we recommend you orange-cloud DNS records that handle HTTP traffic, including A, AAAA, and CNAME. However, do not orange-cloud A, AAAA, or CNAME records used to resolve MX records.  For instance, if you have an MX record that points to mail.example.com as your mail server, orange-clouding the A record for mail.example.com will break your mail traffic.
</pre>

<pre>
However, there are times when some of your DNS records need to remain grey-clouded. For example:

    A, AAAA, or CNAME records used for mail traffic must not be orange-clouded because email routing won’t pass through Cloudflare's proxy.
    When you have to host multiple services (for example, a website and email) on the same physical server

To mitigate this risk, we recommend that you:

    Host your email service in a server (in-house or external) that is different from your site’s origin server
    Analyze the impact of hosting multiple services on the same origin server in cases when having grey-clouded DNS records can’t be avoided
    Orange-cloud all records that share the same origin IP address as your root domain and can be safely proxied through Cloudflare
</pre>

Quote https://support.cloudflare.com/hc/en-us/articles/200168876-Email-undeliverable-when-using-Cloudflare

<pre>
Use separate IP addresses for mail traffic and HTTP/HTTPS traffic. Cloudflare recommends using non-contiguous IPs from different IP ranges.
</pre>

Compatible with SPF, DKIM and DANE?

https://www.secjuice.com/finding-real-ips-of-origin-servers-behind-cloudflare-or-tor/

https://blog.0day.rocks/securing-a-web-hidden-service-89d935ba1c1d

pricing when sending through third party server:

* https://www.sparkpost.com/pricing/
* https://sendgrid.com/pricing/

= Others =
== Qubes ==
Qubes Documentation using jekyll and markdown

pros:

* hosted inside git
* editable through git

cons:

* without javascript there is no table of contents
* without javascript, anchors are broken
* unstable table of contents anchors(?)
* no wiki templates support?
* no footnote support?
* web based editing is cumbersome
** previews so not match actual result
** links cannot be tested if those actually work as expected from github editor
** can only edit whole page, not chapter wise
** github editor does not let one use the browsers internal search function and github editor's one is cumbersome

= See Also =
* [[Dev/mediawiki|mediawiki, codeselect, select code, short / long / recommended / detailed buttons]]

= Footnotes =
{{reflist|close=1}}

[[Category:Design]]

{{Footer}}