Hacker News new | comments | ask | show | jobs | submit login
Show HN: Kloudsec, Our Bootstrapped Anycast CDN with LetsEncrypt for Your Site (kloudsec.com)
64 points by nubela on Jan 14, 2016 | hide | past | web | favorite | 32 comments



Hi everyone, I'm Steven from Kloudsec and we are a 100% bootstrapped startup from Singapore. We built Kloudsec because we wanted to help non-technical website owners find/fix problems.

-----

Kloudsec boasts a

* A true Anycast CDN network with 3 edge locations (London, Singapore and San Jose, US)

* A LetsEncrypt plugin to automatically add an SSL cert to any domain you have (Just enable the plugin, no programming or webserver tweaking needed)

* Offline protection (No error pages when your site is down, still show static contents)

* Experimental WAF (This is hard to get right, we're working really hard on it)

The CDN and LetsEncrypt is 100% free. The premium security plugins are free for now but will be priced later.

-----

[Who should use Kloudsec now?]

As we are in beta now, I encourage you start with casual sites that you don't mind trying with a free CDN and SSL certs for HTTPS.

Happy to take on any questions you have :)


We're obviously competitors (CloudFlare), and I'm not speaking for the company, but congratulations on building this -- it's quite impressive, especially as a small team.


I have nothing but respect for Cloudflare's engineering prowess :)


Couldflare is essential for your company website to be more than a blank page, indeed.


https://www.ssllabs.com/ssltest/analyze.html?d=kloudsec.com

Pretty good but not sure if you need a 4k cert (5651 bytes). That's quite a bit of overhead as well as there shouldn't be a need to send the root cert. Save yourself some traffic. Also, you could probably pare down the cipher list somewhat. The combo of DHE + 4k RSA is probably going to chew up a bunch of CPU unnecessarily.

But pretty nice so far.


More importantly their 4096 bit certificate is signed by a 2048 bit intermediary certificate, so there is no additional security over 2048 bits.


https://tls.imirhil.fr/https/kloudsec.com

SSL Labs is nice, but a bit permissive, not sure anyone really needs 3DES nowadays.


That's a pretty nice site but provides no cues towards what the different colors mean as well as potential remediation.

I can kinda guess at the French words but would rather read it in English.


Hey, wow. The site looks really good, so I connected a domain to try it.

Initial feedback: * I spent about 2-3 minutes to trying to find how to get to the main website settings. Only just before giving up I found the "..." which contained it. I think the "Manage your website settings" settings should be prominently displayed.

* All subdomains (and the domain itself) needs to point at the same ip address? This seems to be a pretty big limitation

* This is definitely the most confusing of the UI: https://i.gyazo.com/dc0f848525e98a08944f839aabbea44e.png I thought it was all a single form. I'd break it up a bit better, and when adding a subdomain explain the steps better (aliasing)

* While my ssl certificate is being provisioned, my site is serving a certificate from organkimlan.com I'm guessing that's another one of your customers?

* I love the idea of real time stats, and route-specific feedback (page load time , errors etc).

Some questions:

* What's your content policy in comparison to cloudflares? (That's probably the single biggest thing I like about them)

* Do you have any guides on how your site respects caching? I really love how cloudfront handles this (unlike cloudflare)

* Are you guys able to eat a DDoS? Is this one of the services you're providing?

Anyway, one of the most impressive Show HNs I've seen in a while. I wish you guys great success and will be following closely


Thanks grapehut.

* No excuses, the website settings look like shit and will be fixed.

* You can add subdomains that point to the same site. (For example, www.example.com and example.com). If you have a different site, you can add a new one in the top right corner. (For example, 2 different websites of "test.com" and "dashboard.test.com")

* On the SSL cert issue, Sorry about this, this is a bug. Our engineers are looking into it. Do you have an email that I can contact you with? You can email us at hello@kloudsec.com and our engineers will immediately help you with this.

* We have no content policy as of now. (This is a schlep and we'll fix this. We'll send an email update once we have this)

* Caching is based on file hashing. Not filenames. You can also manually clear the CDN cache from the dashboard itself.

* DDoS defense. Erm well, we're just lacking 1 last step. Having enough traction/capital to buy lots of bandwidth from our DC to stomach it. We're on it.

Thanks for this feedback. This is insanely useful. We're very excited about this space.


> Caching is based on file hashing. Not filenames.

I'm not really sure what this means, and I've used all the major CDNs/reverse proxies =)

Cloudflare for instance is generally controlled by the filetypes, while cloudfront is generally controlled by the cache control headers sent by the origin server.

Either way, I think exactly how it works needs to go into its own fully-fledged article. It's probably the most important thing a reverse-proxy does, and should be documented very clearly.

BTW one unique feature of cloudfront you might want to support, is setting cache control with vary on cookie. So with cloudfront, I can make non-logged in users see a cached page, while logged-in users see a non-cached page. It allows me to take a huge amount of load off the origin server, with no real downsides (in my case).


My guess is it's a de-duplication trick. They might even have dedicated caching servers. I'd guess others might do it behind the scenes with them just being upfront about it for whatever reason. Just an educated guess.


Could not get any sensible information about how this works, the dash board preview is almost meaningless marketing gunk, which told me nothing about my site.

I got the impression that it would not cope with anything beyond a simple static site.


I'm sorry that our landing page couldn't be better at explaining it. I hope to fix this in the next few iterations.

On the tech, we're a reverse caching proxy service that builds value-add functionalities on the proxy layer.

For example, we can provision LetsEncrypt SSL certs for domains and put it on our edges automatically. All you have to do is to point your domain to our CDN `A` record.

--

On the dashboard, we're trying to help dev-teams, CEOs, etc, to understand the performance of the site.

For example,

- Are there pages that used to be fast, but now regressed to be performing 5x slower?

- Are there pages that used to be functional (200 status code), but now return 500?

Think of it as Google Analytics but for website administration. But I agree that we can be better on the actual info being delivered. But this is our first public launch and it is from here on that I hope to hear from actual users what they want to see in the dashboard.


Quite a lot of inaccuracies in there regarding your competitors...intentional? or just didn't do your homework well?


Is SSL Protection broken currently?

I get this for my domain: 1-Click Encryption FAILED Failed to acquire SSL ceritifate, retrying now..


It takes some time, and will keep retrying. Because LetsEncrypt rate limits us.


Hi

I'm curious, how are you solving the issues inherent in multitenant CDNs like yours (e.g. performance).

Cheers


The word "serious" is misspelled on the main page (says serioues).


Pushing it into master branch as we speak... A few minutes for CI to push to production.


What principal tools are you using for proxy stat parsing & analysis?


(Not the principal engineer but I can try to respond)

We forked nginx (just like Cloudflare) and modified it to log stats that we need. The logs are forwarded to a Logstash, then parsed using ElasticSearch.


What are you plans for an API?


Roadmapped. Probably a few months from now, pending how the market size us up. For example, if the bulk of our users are programmers, then the API will be prioritized.

But if most of our users are non-technical users, then we'll prioritize ease-of-use. For example, the biggest hurdle we face are users asking us "how to change the DNS".


I see your website doesn't work without JavaScript.


Haha, yeah it's a one-page app. And truthfully, we regret splitting up the front-end/backend-API in the day 0 of development. It slowed our dev pace down. Lesson for startups, start with a monolithic app, split it later.


I had to whitelist your domain in NoScript. And also Cloudflare.com... Why are you using your competitors CDN service to serve some javascript on your site? All I saw was a blank page without the assets served from cloudflare's CDN. What kind of CDN are you?


I guess the correct answer is "one that doesn't dogfeeds itself"...


Or keep the same split but render it all server-side (easy with ASP.NET, no idea with other languages).


It's 2016.


and the reasons for not enabling JavaScript haven't changed.


Same here. The actual product looks interesting, however.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: