Pricing page is pretty bad. Draws your eyes with primary colors and bold fonts to $5000/yr and $9900/yr. I had to swallow the sticker shock and look around the page to see the weird, faded side-bubble telling me it's free.
Caddy 0.10 Released
81–90 of 128 posts
Re: Caddy 0.10 Released
#82Caddy is a web server written entirely in Go. Features: - Easy configuration with Caddyfile - Automatic HTTPS via Let's Encrypt; Caddy obtains and manages all cryptographic assets for you - HTTP/2 enabled by default (powered by Go standard library) - Virtual hosting for hundreds of sites per server instance, including TLS SNI - Experimental QUIC support for those that like speed TLS session ticket key rotation for mo…
So is it ready for "prime time"? Should I be considering it over Nginx for side projects or real projects?
I asked this question yesterday. People ask if it's "production ready" but that's like asking if something is "secure" -- I don't really know what that means. Many people use Caddy in production; it's also great for local development. People use it for "real" projects. (I do.) If it is a good match for your needs, give it a try! Start small if you're nervous, but you'll probably like it.
Re: Caddy 0.10 Released
#83The MitM detection is interesting. How long until these appliances start altering the HTTP request's User-Agent header to avoid detection (or adding logic such that the handshaking process mimics that of the browser), though? To me, HPKP with preloading seems like a more reliable approach (and browsers shouldn't allow this to be overridden [1]). [1] If this breaks corporate MitM attacks, great. This practice always s…
> How long until these appliances start altering the HTTP request's User-Agent header to avoid detection (or adding logic such that the handshaking process mimics that of the browser), though?
A TLS proxy that does this is meddling with the application layer and is thus broken (IMO). A TLS proxy that doesn't want to be detected shouldn't mess with the application layer.
The best thing a TLS proxy can do (other than be turned off) is preserve the characteristics of the original TLS connection exactly.
Indeed, Caddy's implementation is mainly for detecting TLS proxies that do a lousy job at it.
Re: Caddy 0.10 Released
#84Is there an official Docker image yet?
No, but this is the one I usually recommend for now: https://hub.docker.com/r/abiosoft/caddy/
Re: Caddy 0.10 Released
#85Earlier quoted context omitted.
This is true; but slowloris attacks don't require opening as many connections. We've seen one or two instances where buggy (or malicious?) clients were slowlorising Caddy instances; but we were too eager to enable timeouts by default I think.
No, not having timeouts is rather bad practice. There are a lot of clients out there that never close connections for various reasons. And since TCP doesn't use healthchecks and most systems by default have limits on the number of descriptors per process, your web server in default configuration will simply leak descriptors and memory over time until the whole thing stops working. The only sane choice here is to have…
Believe me, we wanted to do this, but it broke a lot of WebSocket connections and other legitimate, long-lived connections. It confused many users. It's hard to know what is legitimate and what is not. I wish we could configure timeouts on a per-request basis but not without some serious hacking around the net/http lib for now.
I do encourage setting timeouts when you are able to. It's easy, for example:
timeouts 30s
Re: Caddy 0.10 Released
#86Earlier quoted context omitted.
So is it ready for "prime time"? Should I be considering it over Nginx for side projects or real projects?
I asked this question yesterday. People ask if it's "production ready" but that's like asking if something is "secure" -- I don't really know what that means. Many people use Caddy in production; it's also great for local development. People use it for "real" projects. (I do.) If it is a good match for your needs, give it a try! Start small if you're nervous, but you'll probably like it.
> but that's like asking if something is "secure"
no, that's asking if an enterprise grade project is fronted with Caddy.
> People use it for "real" projects. (I do.)
Sure, but you're not Facebook, Google or Oracle, or big brand X or Z. If you can get Coca Cola, or Nike website run on Caddy, it will change that perception.
Re: Caddy 0.10 Released
#87Earlier quoted context omitted.
So is it ready for "prime time"? Should I be considering it over Nginx for side projects or real projects?
Absolutely use it for side projects! I have used it for a lot of small throw-away sites and loved every minute. It's up to you whether you trust it for large products, but so far it has been fairly magical for me.
[deleted]
Re: Caddy 0.10 Released
#88The MitM detection is interesting. How long until these appliances start altering the HTTP request's User-Agent header to avoid detection (or adding logic such that the handshaking process mimics that of the browser), though? To me, HPKP with preloading seems like a more reliable approach (and browsers shouldn't allow this to be overridden [1]). [1] If this breaks corporate MitM attacks, great. This practice always s…
I'd also be concerned if an employer was doing it, unless there was a good reason - and I can think of a few of those. For example, companies that deal with sensitive health, financial or legal information. They may need assurances (or at least a paper trail) that's a lot stronger than "we don't MITM and we trust our employees to do the right thing".
I've worked at a couple financial institutions where all http/https traffic is proxied transparently (with internal key installed on corp computers)... certainly makes working with command line utils interesting... HTTP_PROXY HTTPS_PROXY are mostly friendly, but some aren't so nice.
Re: Caddy 0.10 Released
#89Surprised there isn't more talk about the MITM detection here. Anyone got a TLDR of how this is supposed to work? I'm going to read the full doc when I get home, but I'd be interested in hearing peoples opinions on how accurate it is likely to be.
The authors of the original paper [1] identified that the set of client cipher suites advertised by each browser can be used to fingerprint and identify a browser.
Caddy records the cipher suite advertised by the client during the TLS handshake and then later examines the client's user agent. Using the fingerprinting techniques mentioned in the paper, Caddy then determines whether or not the advertised user-agent is compatible with the user-agent that it inferred through the client cipher suites.
TLS interception proxies establish their own TLS connection to the server. Depending on what underlying TLS library the proxy uses, it also has its own unique fingerprint. When the TLS proxy forwards the user's request, Caddy detects the mismatch and flags it as a MITM.
Re: Caddy 0.10 Released
#90Earlier quoted context omitted.
I feel like the niche Caddy's trying to fill is for people who don't want to bother with that, or don't want to learn. If you already know how to set up nginx and LE (like you and I do), its only appeal is relatively minor: potentially saving a quarter or half hour.
I think over time there will be a similar server written in Rust, where at least we can be sure that there are no buffer overflows..until then nginx is probably better in every situation.
[deleted]