I am not hosting any services. While just surfing. Why am I having high traffic to let’s encrypt? 
1 Like
What’s that a screenshot from? I don’t recognise it.
2 Likes
Could you give more details ?
- What software do you use to get those stats?
- What is the time period?
- Do you know what means "App Name : Let's Encrypt" or have any more details (domain name, ...)?
When you say that, could you confirm that you do not host "personal" services such as a NAS?
When you visit a website using Let's Encrypt, some web browser (such as Firefox) may check if the certificate is not revoked, using OCSP, which means a small request to Let's Encrypt (probably <10k), and a small answer (also probably <10k) per domain per week (knowing that now a days, a simple website can trigger requests to 10-100 domains).
But those numbers doesn't explains the difference between Upload and download you have, 1.37GB seams too much even for a month a heavy web browsing.
1 Like
hi,
Thanks for responding. This log was from my router and this happen only past 48 hrs.
as for the App Name, it refer to the site we accessing. If I am streaming from YouTube. The App will show as YouTube.
Yes. I am very positive that I do not host any services. NO NAS or any other storage.
I do agreed with with, the 1.37GB is very high. that’s why I am asking to see anyone encountered this before. If not, i might need to trigger a detail log to see the detail packet.
Thanks
hi,
it was obtain from my router log. Which is also use to monitor my traffic
Which brand and type of router are we talking about?
Yes, too high. After consideration, OCSP traffic shouldn't be over 1k per domain, so 1.37 is definitively not just OCSP traffic. Maybe your router is miscategorising traffic? Does your rooter give any other information? Could we have a screenshot with more details (about that traffic and your brand/type of router)?
I have deployed an ASUS Router.
Hi,
I have not drill into the detail of the packet. Is very much high level log. I have just trigger the detail loggin and will have to see the packet information.
as for router. I am using ASUS router.
Thanks
FWIW, I’m seeing something similar on my parents’ home network, behind a Unifi Dream Machine:
It looks like the large majority of the traffic that’s categorized this way comes from a Roku device for some reason, though hundreds of megabytes are associated with two laptops:
They are running no WAN services from their home (and wouldn’t know how to if they wanted to), and nothing related to Let’s Encrypt has been intentionally installed on anything in their network.
It’s worth noting that I’m not sure what timeframe is being used in these reports–it can’t be more than three months, because that’s how long the network has been up, but other than that I can’t say at the moment.
1 Like
It’s interesting that Let’s Encrypt is listed in a category “Network protocols”. Could it be that it sums up all HTTPS traffic to sites which use a certificate from Let’s Encrypt? Or, maybe it sums up all traffic to some port (whatever that may be) where the traffic is protected with TLS and a certificate from Let’s Encrypt? Using “Lets Encrypt” as the protocol name would be a really, really bad idea though… Maybe it’s better to contact the vendor of the applicance and ask them what they mean by that? After all, they decided to label some traffic as “Lets Encrypt”, so it’s their job to explain what they mean by that.
(It’s also interesting that they write Let’s Encrypt wrong - without the apostrophe.)
1 Like
A number of the category choices are curious, and no, it isn't really clear what this refers to. It's broken out separately from "HTTP Protocol over TLS SSL", but so is "Google(SSL)" and "Google APIs(SSL)", both of which use HTTPS. And "Network Protocols" is separate from "Web", or "File Transfer", or "Network Management" (the latter of which includes SMB, which I'd think would belong in either file transfer or protocols)--these are all mutually-exclusive categories of traffic.
I'm not sure if the router would be capable of determining who issued a cert used by a client's connection--would the cert be passed before the connection is encrypted, or after? It isn't doing SSL MITM, but it is doing DPI.
But regardless of the peculiarities of categorization, there's quite a bit of traffic that's being categorized as "Lets Encrypt", and around 2/3 of it is going to a Roku device.
1 Like
I’m not sure for TLS 1.3, but I think for TLS up to 1.2 the certificate was transferred in plain.
(Just checked with WireShark, for TLS 1.2 the cert is indeed sent by the server in plaintext. For TLS 1.3, this doesn’t seem to be the case anymore, the ServerHello message looks like random gibberish.)
1 Like
My topic for clarification on the Ubiquiti forums:
OP, this is likely the best source of information for you as well–nobody here is going to know what your router counts as “Let’s Encrypt” traffic, nor why it would be there.
4 Likes
I agree, though I doubt I'll get any answer (much less a meaningful one) from them. But a post on their forum suggests (as you did) that it's simply anything secured with a Let's Encrypt cert--which, if it's true, is an absolutely idiotic statistic to track.
2 Likes
Even funnier they can only do this for sites (or browsers) using older TLS. TLS 1.3 (and thus QUIC if you're on the bleeding edge) don't transmit the certificate in the clear, so only the server and client even see the certificate in these protocols.
I'd guess most sites using Let's Encrypt today are smaller, hobbyists, one man outfits and so on - so are less likely to use the very latest protocols but that will be gradually changing. This site itself for example offers TLS 1.3 and so would a brand new Linux VPS running many popular web servers.
Thanks for getting to the bottom of this, @danb35!
The heterogeneity of the kinds of things that are tracked in that display kind of makes me think that they wrote a bunch of protocol dissectors and threw all the traffic at them to see, metaphorically, what would stick. Kind of like how in Wireshark there’s a complicated hierarchy of protocol layer dissectors and the summary of an individual packet in the packet list could, under some circumstances, be either more specific or less specific than what you as the Wireshark user are actually interested in. So this looks to me like statistics generated in a somewhat analogous way, where you might get hits at very different protocol layers depending on which pattern-matching within the hierarchy happened to trigger and report something back up the chain or not.
Each statistic that they generate could be very interesting to some users under some circumstances, but the biggest problem seems to be that the statistics aren’t really comparable to one another, because they’re ultimately tracking such different kinds of things!
4 Likes
Well, you're welcome, but I'm not convinced I've gotten to the bottom of anything. The most that I'm confident of having done is that I've found an explanation for what I'm seeing (which doesn't directly do much of anything for OP) that's plausible, in that (1) it's technically possible in many circumstances, and (2) it doesn't conflict with anything else I know about that network. And though this answer doesn't apply to OP's situation, as I'm using completely different routing software, its plausibility does.
So there's a provisional answer, but as is often the case, the answer leads to more questions. Most particularly (1) why did whoever wrote this feature think anyone would care; and (2) if you're going to track certs from one issuer, why not any of the others?
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.