74 lines
3.1 KiB
Plaintext
74 lines
3.1 KiB
Plaintext
# A guide to the Plan9/9front TLS system - Part 1. Servers
|
|
|
|
Editors note: (ok, editor an author are the same here, bu you get the idea) there is a lot of refrences to Plan9/9front specific programs here. If you don't run 9 check out the online manual page repo
|
|
|
|
=> http://man.cat-v.org/9front/ Man pages
|
|
|
|
Much of the work I plan on doing this summer (see my last post) either uses or modifies the 9front tls system. I'm writing this to help myself get a good understanding on how the 9front tls system works and hopefully, you do too.
|
|
|
|
The tls system comes in 3 parts:
|
|
tls(3) - the kernel tls filesystem (fs) (Plan9's motto: "Everything is a file") also known as devtls
|
|
|
|
pushtls(2) the C interface to the tls fs
|
|
|
|
tlssrv(8) the userspace tls tools
|
|
|
|
We're going to review these tools in reverse order to get an understanding on how tls works in Plan9.
|
|
|
|
Ok, imagine you're running a web server with Cinap's tcp80(8) and listen(8) (similar to inetd(8)). In /rc/bin/service/tcp80 you have this:
|
|
|
|
#!/bin/rc
|
|
# my git server stuff would
|
|
# go here
|
|
rfork n
|
|
exec /bin/tcp80
|
|
|
|
The UNIX minded reader already understand's how this works: stuff runs then we use exec to take over the standard input/output of the called script, which would be the http stream coming from listen(8).
|
|
Ok, say we want https because we're not stupid and want to not be tracked by are isp's and vps providers. well, make a cert (see rsa(8)), create /rc/bin/service/tcp443 with this content:
|
|
|
|
#!/bin/rc
|
|
# my git server stuff would
|
|
# go here
|
|
rfork n
|
|
exec /bin/tlssrv -c $certfile /bin/tcp80
|
|
|
|
Boom. you have https. Because of the plan9 philosophy you can do this with smtpd(8), ftpd(8), 9p (exportfs(8)), gopher (tcp70(8)), or even fingerd(8).
|
|
|
|
=> http://fulton.software/docs/meme2.jpg We all get tls!
|
|
=> https://fulton.software/docs/meme2.jpg We all get tls!, but your browser doesn't like my self signed cert
|
|
|
|
This model is great for light tasks Like my blog and low-traffic email server, but not great for a large website or anything that needs that needs to "scale".
|
|
|
|
Ok, now its time for some C.
|
|
|
|
=> https://xkcd.com/371 Segfault time
|
|
|
|
I'm not going to take the time to write out a full web server right now, but I'll give you the short version. To write the server you use listen(2).
|
|
|
|
So you're going to announce that you want a port and ip
|
|
|
|
acfd = announce("tcp!*!9999", adir);
|
|
|
|
check that nothing broke, start an infinite loop, in that loop listen:
|
|
|
|
lcfd = listen(adir, ldir);
|
|
|
|
this blocks the thread until we get something, then you're going to want to fork() and accept the connection with:
|
|
|
|
dfd = accept(lcfd, ldir);
|
|
|
|
dfd is a file descriptor with the connection stream read() to get the input write() to create an output. Ok, now create a tls connection, load the cert and get a tls fd.
|
|
|
|
onn = (TLSconn*)mallocz(sizeof *conn, 1);
|
|
conn->cert = readcert("cert.pem", &conn->certlen);
|
|
fd = tlsServer(dfd, conn);
|
|
|
|
Now all operation on fd (read and write) are tunneled through tls.
|
|
|
|
[much of the code for that example was taken from the EXAMPLES section of pushtls(2) and listen(2)]
|
|
|
|
OK, that's all for now, in my next post we'll be covering tls clients, see you then :)
|
|
|
|
--
|
|
Fulton
|