Phaselockedloopable- PLL's continued exploration of networking, self-hosting and decoupling from big tech

holy shit dude we could all optionally turn it on without hurting our existing configuration

we just have to advertise its available on what we know would work with it. So chrome and mozilla and android browser can go brrrrr (sorry ios)

I guess you could also do add_header Alt-Svc ‘HTTP/2=":443"’; as well

Why didnt I know about this. I will experiment this weekend. I like having options available for all. No reason to stay on a downgraded protocol if the client can support a new one and no reason to break HTTP/1.1 either

I fucking love these russian devs. The one thing the motherland did right other than wodka

Forgot to add this to the blog directory here:

Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX

Yet another drop from my journal

I really am just making it electronic

Series 4: Infrastructure Series -- NGINX Reverse Proxy and Hardening SSL

A good amount of hardening and round robin multiple nginx load balancing can do pretty well

Checkout the rate limitng you can do. That and having a load balancer makes this more effective.

Im doing this now. Im also adding a second droplet for round robin load balancing and both will be optimized according to the docs for high loads

It makes taking it down harder. I dont need CF for that

error_log  /var/log/nginx/$confName$port.log info; 

That can really help store data you need to detect it too!

See my thread: (its long. Also go to the second post for my updated config) that might answer your questions
Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX

Infrastructure Series -- Recursive DNS and Adblocking DoT w/NGINX - #16 by PhaseLockedLoop

I havent updated it for my DoH and DoT changes yet. The pihole setup is a simple filter. The unbound does all of the work. Ive also setup auth zones and hardened the DNSSEC of the unbound. I disabled DNSSEC on the pi to the unbound because there is no point since its local.

Use unbound + DNSSEC not pihole to unbound with DNSSEC. The lookup only matters on the unbound

My network itself is totally open I have a blog post lol: Phaselockedloopable- PLL's continued exploration of networking, self-hosting and decoupling from big tech

It is worrisome but thats the realization of an open source backend. Chromium can be forked and degoogled by anyone and its a better engine. FAR better code

Failure in leadership on the project tbch

Its fine thats why ive moved this discussion to my blog. LOL. See the top of this post

SEE! At one point in time you DID consider using CF in a very specific (and free) use-case… which is exactly what i continue to use it for. There are some decent free tier options, but all the points you made earlier in the previous thread remain valid.

On a side note… the SSLlabs stuff you dabbled in above, is there any value in adjusting what ciphers I’m using? I see your point, but I already managed to get an A+ despite not having things quite as fancy or elliptically curvy as you may:

Cipher Suites:
TLS 1.3 (suites in server-preferred order)

  • TLS_AES_256_GCM_SHA384 ( 0x1302 ) ECDH x25519 (eq. 3072 bits RSA) FS 256
  • TLS_CHACHA20_POLY1305_SHA256 ( 0x1303 ) ECDH x25519 (eq. 3072 bits RSA) FS 256
  • TLS_AES_128_GCM_SHA256 ( 0x1301 ) ECDH x25519 (eq. 3072 bits RSA) FS 128

TLS 1.2 (suites in server-preferred order)

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ( 0xc030 ) ECDH x25519 (eq. 3072 bits RSA) FS 256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ( 0x9f ) DH 2048 bits FS 256

You don’t need to disable this. I just prefer to disable 192 and 128

Just gen a DH 4096 and be golden. You won’t have to regen that for a long time given perfect forward secrecy.

Disabling it was fairly easy. Do so in the openssl.conf globally

I went EC for efficiency. If I can muster sha512 over 256 I will because it’s also more efficient than 256

1 Like

I also hardened my stuff because I realized I would be using DNS over TLS

and choosing the curve that the phone can run really easily AKA ChaCha 20 and keeping with the 256-bit scheme and having an AEAD setup

I knew that would probably be best for what I was doing You don’t necessarily need to do it and also because I know all the devices I’m using are very modern I wasn’t really worried about breaking backwards compatibility

Seeing as your server supports TLS 1.3, that should mean you have OpenSSL 1.1.1.

Might be worth getting rid of the DHE AES 256 for something like this: ECDHE-RSA-CHACHA20-POLY1305

I don’t have a super deep understanding of webservers and why one might want more than two cipher suites active, I just run as it works for me.

1 Like

When I’m done with my exercise I think I can pull my SSL conf

It’s a dirty hack but it works for both of you and I so

If you scroll down on the SSL test you can actually go down and see if you’re vulnerable to anything that’s weak

You’ll have to scroll down quite a bit and expand most of the menu items

These type weak vulnerabilities?

Didn’t all quite fit on a page, probably should have tried to use Pastebin, i dunno. Sorry for the spam.

I’m not really married to any of these technologies, I’m just trying to learn a thing or two while I tinker and (hopefully) try to improve the computing experience for family and try to maintain those rigorous SLAs. >.<

Debian GNU/Linux 10 (buster)
OpenSSL 1.1.1d  10 Sep 2019
nginx version: nginx/1.18.0

This is just a little VM i run since migrating the web server off my RPi3B so I could repurpose that for a little ADS-B project attempting to learn a few basics about radio waves and the surrounding technology. The thinking was that it might better equip me to deal with WiFi related matters. Sorry, now I’m delving a bit further off topic. You guys are great.

then you fine but honestly all I did in openssl was this

Disclaimer im not resposible for broken systems

ssl_conf = ssl_sect

system_default = system_default_sect

MinProtocol = TLSv1.2
CipherString = [email protected]=2
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Options = ServerPreference,PrioritizeChaCha

Also everywhere I saw sha256 I changed to sha512 and anything RSA2048 to 4096

[ req ]
default_bits		= 4096
default_md		= sha512

Bingo and Im good

Also some other things I did were

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 19
challengePassword_max		= 29

changed from 4 and 20

1 Like

I keep churning it out man:

Series 5: Infrastructure Series -- Taking DNS One Step Further - Full DNS Server infrastructure

1 Like

Apologies if I haven’t found it skimming through the thread but since I am now the owner of a Pixel 4a I’d like to follow your steps on getting the phone set up since my last lineageos setup was pretty tashy. Have you already written more specifically about what steps you took or could you if not?

1 Like

The 4a isn’t officially supported. So my steps won’t be applicable until it gets supported.

The 5g version will take even longer.

1 Like

Yeah I’ve seen that, my hope is that it overlaps greatly with the 4 though so I wouldn’t discount your steps being helpful or at least some general guidance.

It’s not the 5g version

1 Like


Doing this


1 Like

My instructions dont really differ to much from building from source? I guess I should ask for clarification on what you need?

Its the only way to actually sign the ROM and make it into a factory image

Hacking there script up to work with the lineage OS Build

However you can just build it and skip signing and relocking the BL. thats the easiest route and honestly just fine