Wakaba
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
https://wakaba.dhcp.io/
Hey /g/, don't know if you remember but i posted this here a while ago, this is a simple file host service with backend written in C I'm working on just for you.
Improvements/upsides:
- CA signed certificated. (https://letsencrypt.org/certificates/)
- No more port 4433/8080 (still active for backwards compatibility though), replaced by NGINX reverse proxy.
- Randomly picked waifus.
- Gzip via reverse proxy.
- Stronger TLS via reverse proxy.
- Forced TLS.
- File limit raised to 128MB.
- Been alive since August this year and will stay alive for as long as i can keep it alive.
- Doesn't use Pomf.
- No filetype limit.
- No PHP in backend.
- No SQL.
- No JS or meme JS libraries.
Drawbacks:
- Australia.
- Backend is still an independent HTTP server.
- File extension isn't preserved.
Hope you find it useful.
Forgot to mention it's also open source.
>>51765490
it doesn't make sense to call a web service open source
you are offering a service, not a program
>>51765515
The backend is open source, meaning you can clone it, modify it, redistribute it and run your own version.
b-bump
>>51765177
>Drawbacks: Australia
Has this ever been a problem whatsoever?
>>51765543
You can't prove that what is running on the server is what is on the github account.
Nice TLS m9
>>51765177
> AES256-CBC
> Not AES128-GCM
> SHA1
> ECDHE instead of DHE
What the fuck are you doing mate ?
Are you working for the NSA ?
>>51767054
In addition
> Using SSLv3
> Using 1024-bits common DH prime
Really? Are people this stupid exist ?
>>51766936
Read the third sentence below "How to upload?" and stop using shitty phone browsers.
>>51767155
SSL isn't enabled though, I'm only allowing TLS.
Atleast that's what the nginx default is, maybe i'll go set it explicitly then.
>>51767198
Well I am still able to force SSLv3 so that mean you are fucked up.
And go change those DH prime to something better.
Also do not use ECDHE as NIST curves are not to be trusted. Use DHE instead. Forbid SHA1 also.
Why did you have to name it Wakaba?
https://wakaba.c3.cx/
https://www.google.com/#q=wakaba
>>51767366
I don't know, do you have a better name?
>>51767350
>Well I am still able to force SSLv3 so that mean you are fucked up.
I just explicitly set nginx to only allow TLSv1.2, so try again.
>And go change those DH prime to something better.
How? what's the directive?
>Also do not use ECDHE as NIST curves are not to be trusted. Use DHE instead.
Fixed.
>Forbid SHA1 also.
Ok, but why?
>>51767420
Oh, yes. Plenty. Try iphone. If that doesn't work, maybe 4chan. Trump also a good name. Intel. 2006 Winter Olympics. My Little Sister Can't Be This Cute. Violent Semen Inferno. Also Kareha.
>>51767420
https://bettercrypto.org/static/applied-crypto-hardening.pdf
>>51767420
> https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwakaba.dhcp.io%2F&hideResults=on
Disable SSLv3 from openssl, compile it with no-ssl3 flag instead.
> How? what's the directive?
openssl dhparam -out dhparam.pem 4096
Tell nginx to use them:
ssl_dhparam /etc/ssl/certs/dhparam.pem;
>Forbid SHA1 also
SHA1 is now considered unsafe.
i'm not the OP but do you have any resources for good crypto standards i could check out, blog posts / wiki articles / stuff like that?
>>51767491
meant for
>>51767481
>>51767350
https://mozilla.github.io/server-side-tls/ssl-config-generator/
can I upload CIA?
>>51767481
Cont.
This is the point where most crypto system fucked up. It failed not because of the crypto itself is weak but the implementation.
Here we have OP who did not disable SSLv3 and change DH params, which renders his shiny ECDHE-RSA-AES256+CBC-SHA1 useless.
To OP
Also consider using HSTS and OCSP.
And chain your your cert from letsencrypt properly as most browsers still do not trust letsencrypt cert.
>>51767535
>Also consider using HSTS and OCSP.
What are they?
>And chain your your cert from letsencrypt properly
What does this mean and how?
DH params are currently generating.
>>51767576
Just fucking google it.
>The database is held on a 2TB dmcrypt volume, however there isn't much space remaining.
>The server is hosted in Australia on a shitty non-business connection with a torrent client running half of the time on the same connection.
Why would we want to use this shit?
>>51767763
Because you can host your own instance.
>>51767763
Well we supposed to test the software, not using it as a replacement for pomf
>>51765177
Fix your TLS:
https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwakaba.dhcp.io%2F
How fucking long does it take to generate the DH primes?
>>51767763
I'm buying an additional 2TB (maybe more) disk sometime soon and going to LVM it with the current one.
And about being in Australia with shit internet, can't do much about it.
I'm in one of the good areas too.
>>51767784
I never said that.
>Hope you find it useful.
But yeah you can host your own instance.
>>51767535
I enabled HSTS and OCSP, however SSL labs still says that OCSP is disabled.
>>51765177
What about IPv6 and HTTP/2 support?
>>51767854
>IPv6
I don't have IPv6 myself, and i don't care.
>HTTP/2
Introduced in nginx 1.9.5, I'm on 1.8.0 from repository.
I'll compile the new version maybe later.
>>51767847
>How fucking long does it take to generate the DH primes?
On a quad-core i7: 1 hour
This because openssl using what is called "safe-prime". DH prime are 1/10000 primes genarated and "safe-prime" is 1/10000 of that. Forget to suggest you do not gen primes on a toaster.
> I enabled HSTS and OCSP, however SSL labs still says that OCSP is disabled.
OCSP reported invaild because you do not chain your key. You need to add
ssl_trusted_certificate [.pem];
Using the same fullchain.pem you used.
>>51767854
>IPv6
A meme
>HTTP/2
A even bigger meme. There is no use for it right now.
botnet :( do not trust
>>51767971
>ssl_trusted_certificate [.pem];
>Using the same fullchain.pem you used.
Did you not see the attached image? i did exactly that.
4096bit DH primes is now active.
>>51766672
has it ever not been a problem?
>>51767997
Output of openssl s_client -connect wakaba.dhcp.io:443depth=0 CN = wakaba.dhcp.io
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = wakaba.dhcp.io
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=wakaba.dhcp.io
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
Normally, it should beCONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1
verify return:1
depth=0 CN =******
verify return:1
---
Certificate chain
0 s:/CN=*****
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
That mean you did something wrong with the cert.
>>51765177
Pomf developer here. Wakaba'sgit-log(1)still scares me.
I still like Wakaba's idea of using a non-meme programming language. PHP is awful. I am still dubious if C can be integrated well into OpenBSD's HTTP stack.
> Randomly picked waifus.
I'm concerned if the waifus distributed with Wakaba can be legally redistributed. I would suppose they at least require attribution. Some license information and sources would be nice.
> Doesn't use Pomf.
I'm curious what's wrong with Pomf. Have you seen the latest Pomf 2.0 development snapshot?pantsu/pomfis nearing 2.0.0 release and a lot of the cruft has been removed.
> No JS or meme JS libraries.
Luminarys is working on non-meme JavaScript for Pomf 2.1 release. A working prototype already exists.
>>51766672
Warrant canaries are outlawed.
>>51768015
If your cert is RSA2048, then you should be using DH2048. I didn't check what your cert is.
Regardless, RSA4096 is not the best practice.
>>51768110
>Wakaba'sgit-log(1)still scares me.
You said this last time and i still don't understand what you mean, why is it scary?
>I'm concerned if the waifus distributed with Wakaba can be legally redistributed.
I thought this would be a problem, no ones going to give a fuck right? otherwise, where can i find some free as in freedom waifus?
>If your cert is RSA2048, then you should be using DH2048. I didn't check what your cert is.
Another anon told me to generate 4096bit primes, and I'm not generating another one so I'll stick with that.
>>51766847
open source isn't about verifying what's running, if you don't trust it compile and setup the github
Well i can't seem to get forward secrecy and proper certificate chaining working so I'm just going to leave it at that, it's good enough for now.
Meanwhile, anything that can be improved here?ssl_certificate /etc/wakaba/server.crt;
ssl_certificate_key /etc/wakaba/server.key;
ssl_ciphers EDH+AESGCM:EECDH+ECDSA+AESGCM:EECDH+AESGCM:AES256+EDH:AES256+EECDH:HIGH:!aNULL:!eNULL:!EXPORT:!RC4:!DES:!MD5:!SHA1:!LOW:!3DES;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:ssl:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/wakaba/fullchain.pem;
ssl_client_certificate /etc/wakaba/fullchain.pem;
ssl_dhparam /etc/wakaba/dhparam.pem;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
>>51768110
wub get out
calling yourself a pomf developer is like saying you built a bridge because you paid taxes. protip: you didn't build that. You manage a BRANCH of pomf.
>>51768110
>RSA4096 is not the best practice
Why? If you want to support of Android 2.2.1 and IE7 then yes. If no then there is not a problem with RSA-4096 performance-wise and compatibility-wise.
>>51765177
Also for the sake of security, disable all cipher that do not support FS. Nobody use IE6 anymore.
Also add these line to the beginning of nginx to disable content sniffing.add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
>>51768156
> You said this last time and i still don't understand what you mean, why is it scary?
Minor inconveniences. Git subjects are too long in some places and there is no empty line between the subject and the commit message.
Please read Chris Beams' "How to Write a Git Commit Message".[1]
> I thought this would be a problem, no ones going to give a fuck right? otherwise, where can i find some free as in freedom waifus?
Technically it's illegal to redistribute those. It can also cause problems for packagers, e.g. if ever packaged to Debian they would have spend time removing the waifu pictures from the distribution to satisfy Debian Free Software Guidelines (DFSG).
As for free as in freedom waifus, the Pantsu.cat developers have previously researched this. We only found few waifus to fit that criteria, but their heads were cropped as part of the artistic style so they were unfit for our needs.
> Another anon told me to generate 4096bit primes, and I'm not generating another one so I'll stick with that.
4096-bit is 2.5 to 3 times slower than 2048-bit and provides no extra security when your RSA key is only 2048-bit. You can benchmark this withopenssl speed rsa2048andopenssl speed rsa4096.
If your RSA key was 4096-bit, then there would be a negligible security improvement at the cost of performance.
[1]: http://chris.beams.io/posts/git-commit/
>>51768189
See Partyvan's nginx ssl.conf configuration for help.[2] I can also guide you. Are you available on IRC?
[2]: https://partyvan.eu/transparency/config/nginx/ssl.conf
>>51768241
>If your RSA key was 4096-bit, then there would be a negligible security improvement at the cost of performance.
The cost of performance is pretty negligible except when you are serving tens of gigabit of users.
RSA-2048 only provide 112-bits keys while 4096 provide about 144-bits keys, which are suitable for AES 128-bits keys.
>>51768241
I admit I'm pretty shitty at writing commit messages, thanks for the link.
>Are you available on IRC?
No.
Forward secrecy is properly working now.
>>51768189
>ssl_trusted_certificate /etc/wakaba/fullchain.pem;
This should be the intermediary only to avoid anchoring/chain issues.
>ssl_client_certificate /etc/wakaba/fullchain.pem;
Drop this, I don't think it applies to you.
>add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
I suggest to add the non-standard preload parameter to this header and submit it for preloading at HSTS Preload Submission.[1]
[1]: https://hstspreload.appspot.com/
>>51768338
By the way, sending the intermediary Let's Encrypt X1 certificate should also resolve those mobile browser issues.
Assuming mobile browser users would have to install it themselves can cause more problems with security anyway.
>>51768338
Also right, sorry, you can't preload HSTS without registering your own second level domain.
>>51768338
>This should be the intermediary only to avoid anchoring/chain issues.
By intermediary you mean Let's Encrypt Authority X1? tried it but it didn't solve the chain issue.
>>51768464
> By intermediary you mean Let's Encrypt Authority X1? tried it but it didn't solve the chain issue.
Yes, I mean the X1 certificate. Did you remember to reload nginx? Right now the X1 certificate is not sent by your web server, resulting in an extra download.
Once SSLLabs recognizes X1 as root certificate (if ever), it should be removed fromssl_trusted_certificatefor what it's worth.
>>51768479
>Did you remember to reload nginx?
Obviously.
>Right now the X1 certificate is not sent by your web server
Well it should because it's right here.
>>51768496
What's the output ofnginx -t?
>>51768505
Systemd would've complained if something was wrong.
>>51768517
Please paste the full/etc/wakaba/intermediate.pemfile.
>>51768531
No you shouldn't. I suggest you run letscrypt again
>>51768557
The intermediate certificate is only the publicly available Let's Encrypt X1 certificate. The/etc/wakaba/intermediate.pemshould not contain any private keys.
>>51768531
It's the same certificate linked on the front page.
http://pastebin.com/U80v1gw7
>>51768577
Looks fine to me. This is an nginx configuration issue somewhere.
Could you paste all the nginx configuration files you have/are using?
>>51768577
>>51768599
I also suspect this is not a permissions issue, becausenginx -tdoesn't complain.
>>51768599
Ignore the mixed spaces and tabs, http://pastebin.com/SABB2p1Z
>>51768632
I can't immediately find a fault. However, there are other issues:
>ssl_certificate /etc/wakaba/server.crt;
The filename should probably have a .pem file extension.
>gzip_comp_level 9;
Performance issue. Use level 5-7.
>gzip_types *;
Violates compatibility (standards?) and a performance issue. Do not gzip binary data.
>add_header X-Frame-Options SAMEORIGIN;
add_header X-Frame-Options DENY;
Duplicate header.
>error_page 403 /shared/403.html;
error_page 401 /shared/403.html;
Duplicate markup. Useerror_page 401 403 /shared/403.html;.
># Force SSL.
Incorrect. Should read "Force HTTPS", which refers to TLS.
>location ~ \.(jpeg|jpg|png|gif|ico|webm)$ {
expires 365d;
}
Other static content is not cached, e.g. CSS.
>>51768682
Of note,ssl_certificate /etc/wakaba/server.crt;follows immediately aftergzip_types *;. That may be your issue.
>>51768632
>default_type application/octet-stream;
I am actually experiencingdefault_type text/plain;behavior in/files/.
>>51768682
>>gzip_comp_level 9;
>
>Performance issue. Use level 5-7.
I'm sure the network latency is much higher than compression latency, i need to squeeze as much as possible out of my Australian internet.
>Do not gzip binary data.
Ok you're right about that.
>Other static content is not cached, e.g. CSS.
Because what if i change the CSS? besides, the sites CSS is embedded into index.php so there's no point.
>>51768742
That's because requests to /files/ is proxied to the wakaba backend server which does it's own HTTP and shitty SSL, which i will soon strip those things out of wakaba and just let nginx take care of it, the problem with that is that i'd have to handle file POST's and GET's in php and send them to the daemon manually.
And text/plain is intentional.
>>51768703
Changed it, didn't fix.
I don't see why it would be an issue anyway.
>>51768776
I don't know what else I could do for you. I assume your nginx isn't sending the certificate. Start writing your configuration from scratch one part at a time and see where the issue is.
Or take the black horse and switch to OpenBSD httpd. No need to worry about complex configurations while everything is secure by default.
> I'm sure the network latency is much higher than compression latency, i need to squeeze as much as possible out of my Australian internet.
gzip compression is a contributing factor to latency.
There is next to no difference in compression level after level 7. In other words, level 7 is the best you can get.
You could run a CDN in front of your server to reduce the amount of bandwidth required.
> Because what if i change the CSS?
ThenLast-Modifiedand/or ETag headers tell the browser to fetch a new CSS file if it has been changed.
Right now they're not cached at all (or for very short periods of time), resulting in a performance penalty.
> And text/plain is intentional.
Seems to break various binary content uploaded to the service.[1]
[1]: https://wakaba.dhcp.io/files/a
>>51768820
Okay, i put gzip level down to 7.
>Then Last-Modified and/or ETag headers tell the browser to fetch a new CSS file if it has been changed.
I thought expires overrides last-modified/etag.
>Seems to break various binary content uploaded to the service.
Werks for me.
Would preserving file extension fix that for you?
I don't know any other way to detect file type other than reading magic numbers, so i just let the browser guess, which chromium seems to fail at.
>>51768884
The HTTP/1.1 standard requires sending theContent-Typeheader with content in RFC 2616, usually followed withContent-Lengthheader. This seems to be missing.$ curl -I -k https://wakaba.dhcp.io/files/a
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Wed, 09 Dec 2015 09:13:38 GMT
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubdomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
>>51768884
>>51768913
Oh right, but this is nginx MIME configuration related I suppose. And you're already aware the extension is missing.
>>51768913
Wakaba actually uses HTTP/1.0, but i guess the nginx reverse-proxy is overriding that.
I'll look into a way to stop nginx from doing that.
