It's investigation time! HTTP/2, AltSvc and SSL

[ghost]

TBB enabled both HTTP/2 and Alternative Services on the release channel in September, following two audits : HTTP/2 and AltSvc. It is indicated that these protocols no longer pose a threat to privacy when FPI is enabled. Therefore, I suggest we consider commenting the related prefs (0702, 0703) and add a warning that they need FPI enabled to be safe, privacy-wise. However, @Thorin-Oakenpants 👖 raised a fair point in #107:

I think SSL session ticket ids is closely related. The thing is TBB is different - it uses tor and changes circuits (I'd have to check now, but it used to be every 10 minutes)

It would be kinda cool to know if SSL session tickets are required for HTTP2 and AltSrv, because that's the overriding factor in even allowing them in the first place. Currently FF only wipes SSL sessions on FF (or last PB mode) close, otherwise it allows up to 2 days (and I'm not sure if it respects that, eg if a site says the id is valid for 5 days, what does FF do, and vice versa if the site says its shorter)

As the title states, it's investigation time! Does anyone know who we could reach out to to get an answer? Could some experts share their insights on the matter?

P.S.: Now THIS would be a perfect issue for your "NEEDS JESUS" label, @claustromaniac! :cat2: Also, can I add the "help wanted" label or that restricted to the big E and 👖 ?

[Thorin-Oakenpants]

When I say closely related, I mean that they may be required, either technically or for any speed improvement (which IMO is the only reason for this). While HTTP2 allows for HTTP in the spec, it is not supported by the browsers, so for all intents and purposes, SSL is always used

https://en.wikipedia.org/wiki/Http2#Encryption

Although the standard itself does not require usage of encryption,[30] all major client implementations have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory

[Thorin-Oakenpants]

Here is a discussion I had with Tom Ritter (Mozilla) and Arthur Edelstein (Tor)

[Thorin-Oakenpants]

Part 1: get an definitive answer if SSL session ids are required

Does anyone know who we could reach out to to get an answer

Tor's IRC channel (but be prepared to lurk in there, it's not like users watch/read it 24/7).

I also have a "direct line" to Arthur & Tom. They tolerate me, but I feel like I must be a bit of a pest to them at times. They seem to be generous and never ignore me, but I do limit my pestering, as I know they are super busy.

I guess we should inspect the technical documents, or ask on a reddit /networking thread or something. Even r/tor .

---

Part 2: ask Firefox to reduce the SSL session id time (see email pic in previous post)

The thing is Tor doesn't really care about the length of these ssl session ids. If they are required (and TBB flipped all three for a reason), then because Firefox doesn't protect from it via new identities/circuits/nodes/guards or whatever you want to call it (like tor does), then we would have to appeal to Mozilla

PS: it would be nice to know or confirm if temporary containers wipe ssl session ids

[Thorin-Oakenpants]

PS: it would be nice to know or confirm if temporary containers wipe ssl session ids

Ignore that. If using TC, then each (new) container (contextid) already isolates them. Still would be nice to know if the API also includes this

https://github.com/ghacksuserjs/ghacks-user.js/issues/395#issue-310329383 ( @stoically )

Temporary Containers only uses one API to remove data, and that is contextualIdentities.remove - which removes all userContextId tagged storage (including IDB). And even if it'd fail to do so, new contextualIdentities couldn't access the same data, since the cookieStoreIds (that's how the attribute is called in the API - it however refers to the userContextId used to OA-tag) are unique as long as the container feature is active.

So does this API cover SSL session ids (edit: for those cases where you keep/re-use a container)

[ghost]

@Thorin-Oakenpants Part 1 : I'm registering to OFTC to get some answers on #tor-dev, I'll keep you posted.

Part 2 : Tom Ritter mentioned we should be asking Mozilla, and I read you weren't keen on opening a ticket yourself. Would you like me to open one with our current questions and your suggestions from the mail? (I'm unfamiliar with the tracker, I'm completely new to this, but I learn at an okay speed so I could do that.)

On the matter of your "direct line", I completely understand you'd rather use it as little as possible, no worries there, we'll find the solution(s ?) together!

[Thorin-Oakenpants]

OFTC

WTF is that?

Tom Ritter mentioned we should be asking Mozilla

He is Mozilla :) Ethan's team is the Tor Uplift team, and since my proposals go beyond that, then all he was saying is that we would have to appeal to the higher ups. I see no problem with any of my logic - reducing to 30 or 60 minutes as per other major browsers.

The problem then becomes getting RFP or PB teams interested in reducing it to 10 minutes or even less (I want a pref and I can which I can set to 1 minute). And none of them are interested. PB mode because all data is destroyed on session end, and their mandate (despite the name) is not leaving persistent local data. And RFP because they have FPI. And Tor, because they are using a different protocol that changes nodes frequently and also have FPI. And all of them will say, but its a SSL session id, so closing the browser always clears it.

So having said all that, I don't think it's even worth my time to try and convince anyone. Reducing it to 30 or 60 minutes would be cool, but not enough to justify using it (for myself), and after that no one F cares

So it wasn't that I wasn't keen to open a ticket, but that by getting Tom to open it instead gives it more weight - but that didn't happen. As for you opening a ticket, I would rather you didn't. It needs to be worded correctly or it'll just get shut down. We don't need to ask questions, or mention RFP or PB mode - we aiming at a difference audience now. IF it was to happen, then after it lands, then we push for MOAR in RFP/PB mode. Let's chew on it for a while.

[ghost]

< Aeriem> Hello, I have a question on the handling of SSL tickets in regard to HTTP/2 and AltSvc, is this the right place to ask?

<+GeKo> Aeriem: not sure. maybe ask? <+GeKo> those tickets are isolated to the url bar domain fwiw <+GeKo> (not sure if that already answers your question :) )

< Aeriem> GeKo: In v8, TBB enabled both HTTP/2 and AltSvc (and SLL Tickets IDs) after audits that stated those protocols where safe (privacy-wise) when FPI was enabled. But 1) do these protocols requires SSL Tickets IDs to be enabled in order to work correctly and provide any speed improvement; 2) And did the TBB Team enabled those three techs because TBB doesn't really "care" about tickets IDs since they are wiped every 10 mins? < Aeriem> GeKo: On vanilla Firefox, the SSL Tickets IDs are kept until browser closure or end of life of the ID, which could potentially be a privacy issue, and could require a ticket to FF bugtracker to ask for the possibility to wipe those every 10 mins via a pref < Aeriem> GeKo: Also I assume you mean SSL Tickets IDs are affected by FPI when you say they are isolated to the url bar domain?

<+GeKo> Aeriem: yes, that's what i mean <+GeKo> no, http/2 and altsvc don't require those tickets <+GeKo> and, yes, http/2 in particular should give you speed improvements <+GeKo> we noticed as well that some sites are even broken without having http/2 enabled <+GeKo> i.e. they are alredy http/2-only <+GeKo> regarding 2) <+GeKo> those tickets are not necesssarily wiped every 10 minutes <+GeKo> but their cross-domain tracking potential is neutered with first-party isolation <+GeKo> we don't tackle possible tracking with session ids (or session resumption) by fist parties <+GeKo> as a) there are plenty of things they can use which are much better tracking tools (like cookies) <+GeKo> and more imortantly b) first parties are usually those parties the user wants to interact with <+GeKo> against those we have the new identity feature that you could and should use once in a while <+GeKo> to give you a new, clean tor browser state

< Aeriem> GeKo: Thank you for taking the time to answer, this was very helpful! < Aeriem> GeKo: Just a precision: when I asked if HTTP/2 and AltSvc required SSL Tickets, I meant in the real world, not in the specs. I know they don't require it to work, but I read that many browser implemented the tech in a way that it only works over TLS connections, so is that something to consider? < Aeriem> Also, I was asking if HTTP/2 would bring speed improvements without SSL tickets IDs enabled, not if it brought speed improvements in general, I worded my sentence poorly, sorry!

I'm waiting to get the answers to my last questions, feel free to suggest what I should ask if something bugs you.

From what I understand, those three protocols (HTTP/2, AltSvc, SSL Tickets IDs) are safe with FPI enabled, and even if first parties have access to the tickets, even TBB doesn't do anything against that (nothing is done every ten minutes when it comes to them, no deleting, no change of ID, even the change of node doesn't affect them), they just suggest to use the new identity feature once in a while, which would translate into closing FF sometimes for us. All in all, the privacy issues rising from these doesn't seem very concerning, especially considering that even TBB finds it negligible, furthermore it is quite easy to counter by closing and reopening FF, what's your opinion? At this (early) stage of the investigation, my suggestion is disabling the prefs relating to those techs, and add a comment like this:

If you disabled First Party Isolation (see 4001), consider disabling this protocol as it might leak some data without FPI. special edit for HTTP/2: This protocol is progressively becoming more mainstream and some sites break without it because they are not available in HTTP/1 versions.

[ghost]

@Thorin-Oakenpants OFTC is the IRC to contact the Tor devs, at least that's what's written on their official contact page. Also I understand better your current stance on the matter, thanks for the explanation! Read my last comment and let's decide what we do about this in the user.js.

[Thorin-Oakenpants]

From what I understand, those three protocols (HTTP/2, AltSvc, SSL Tickets IDs) are safe with FPI enabled, and even if first parties have access to the tickets, even TBB doesn't do anything against that

Nope. If the session id hasn't expired, then you can be tracked by it. No one seems to give a F about repeat first party visits. Example:

• Am on VPN A: I do a google search
• Flip to VPN B: I do another google search

So seems even TBB don't give a sh^t unless you specifically request a new identity. I can't understand why there isn't a pref to set max lifetime to 1 or 10 minutes

[Thorin-Oakenpants]

I see no problem with making HTTP2 and AltSrv inactive, but session tickets remain a mess. We don't want half measures, we want proper solutions and expect worst case scenarios in our thinking. Seriously, I would have to close my FF and my 4 or 5 tabs, and lose my train of thought/work .. just to clear session ids. Bollocks. We need a better solution than "oh but FPI".

We have a better solution, just using a different OA: TC (temporary containers)

Would making those two inactive make a speed diff? Probably. Wait and see what Geko says. Or find me some sites and I'll do some bullshit perf testing

[Thorin-Oakenpants]

Ahh OK. I've always used a different one with Arthur - the Tor Uplift one

[ghost]

100% agreeing with you, I underestimated the tracking potential, also I get how having to close your browser all the time for privacy would be a pain in the bum, didn't think about it that way, sorry about that. Then we could make the prefs for HTTP/2 and AltSvc inactive and let the SSL Tickets IDs prefs as they are until a pref to set their lifespan manually is created, that way we enable HTTP/2-only websites and keep the SSL Tickets mess at bay. The only problem is: does HTTP/2 work without them in Firefox ? We would need an HTTP/2-only website to test this, ideally HTTP/2 would work with SSL Tickets IDs disabled and we could close this issue and make a commit. Also I don't think perf is an issue here. Only compatibility is a matter of importance, considering HTTP/2 is becoming the new standard and HTTP/1 will progressively be abandonned.

[Thorin-Oakenpants]

The only reasons to enable all this is for speed and compatibility. If there's no real speed diff (without session ids) then what's the point. As for HTTP2-only sites, IMO they would be super rare. Any site that did that would be shooting themselves in the foot. We could probably sit on this for a couple of years with no issues.

The only problem is: does HTTP/2 work without them in Firefox ?

GeKo said yes. Waiting on his answer re any speed improvements. Look, I'd read somewhere that the speed increases are quite good overall. A lot of 30%'s thrown around in some real world tests (nah, can't find the sources, it's all in my head). And, i think, now over 50% of the top x sites are HTTP2 compliant (see Scott Helme's Alexa 1M 6 monthly scrapes). So it's definitely something to consider.

[ghost]

He didn't send me anything since what I copied-pasted for you, so I sent him another message, I'm in wait of his answer. :)

As for HTTP2-only sites, IMO they would be super rare.

According to GeKo, they aren't anymore, seems like they're becoming a thing, but I still get your point.

We're left waiting for an answer regarding speed without SSL tickets, and then we'll be able to close this one! 🎉

[ghost]

P.S.: You mentionned TC, what do they bring that normal containers wouldn't? I get that the automation is neat, but can't you do the same thing by just opening new tabs in new normal containers that you enabled in a recent commit?

[Thorin-Oakenpants]

OA = Origin Attributes. There are three types: FPI, PBmode, containers. Almost everything is tagged with these (not everything, but they're getting there). And they can be combined (except containers can't be used in PB mode)

If you open a PB window, everything in it and subsequent PB windows until all PB windows are closed, are the same OA. So this would allow cross-domain "contamination".

Each container you set up has a unique id (eg contextId=1). But you can re-use them, eg the default four that come shipped with FF. Each container is isolated - but allows cross-domain contamination: eg a google container that allows gmail+google+youtube+gstatic+googlefonts etc. You can combine this with FPI, but until FF is closed, SSL session ids would remain

If you use FPI, then everything is tied to the top domain

A TC is one where every new tab gets a brand new OA. i.e contextId=lastone+1. So every new tab is isolated from all other tabs.

note: SSL session ids are OA'ed (we should check that it isn't just FPI but also ContextId and PBmode!)

[ghost]

I wanted this extension to be useless, I really did, but it's not and now I'm going to have a new one, I hate great devs. Thanks to your explanations, I understand its benefits way better. You're a great teacher, thanks a lot, I feel like I'm getting helped more than I'm helping haha!

[ghost]

Just interfering to make sure I get your comments correctly.

So we'd have at this time,

Consider commenting 702

// 0702: disable HTTP2 (which was based on SPDY which is now deprecated)
// pref("network.http.spdy.enabled", false);
// pref("network.http.spdy.enabled.deps", false);
// pref("network.http.spdy.enabled.http2", false);

Consider commenting 703

// 0703: disable HTTP Alternative Services (FF37+)
// pref("network.http.altsvc.enabled", false);
// pref("network.http.altsvc.oe", false);

Keep disabling session ticket

// 1203: disable SSL session tracking (FF36+) -- aka session ticket
pref("security.ssl.disable_session_identifiers", true); // (hidden pref)

That's what I'm doing. Commenting 702 & 703 but not 1203. Moreover if speed increase is likely with 702 & 703, not sure allowing session tickets improves speed when it is obvious it is a privacy issue.

[ghost]

@StanGets We should add the comment I suggested to push users to enable FPI when they use these protocols. The speed increase from HTTP/2 is partially based on the fact that SSL tickets don't have to be created all the time, which is a quite heavy operation since it requires cryptography. That's why it could lessen HTTP/2's benefits if we disable them. @Thorin-Oakenpants Correct me if I'm wrong please!

[ghost]

@Aeriem provided FPI is enabled, of course; that was mentioned at the very start. I have FPI enabled so I forgot to recall this correlated setting.

Concerning session tickets I do rely on @Thorin-Oakenpants comment above:

The only problem is: does HTTP/2 work without them [note: session IDs] in Firefox ?

GeKo said yes

Just trying to follow your expert comments. Thanks.

[ghost]

@StanGets No worries !

HTTP/2 will work without SSL tickets, this is in the specs of the tech, @Thorin-Oakenpants said so and linked some doc to prove it.

What we don't know is the actual speed benefits from HTTP/2 when they are disabled, because some of those benefits rely on keeping those tickets a long period of time to avoid doing complex mathematical calculus each time you reach a website. I don't know if I'm being clear. T-T

[Thorin-Oakenpants]

We should add the comment I suggested to push users to enable FPI when they use these protocols.

We would create an FPI Alts section

partially based on the fact that SSL tickets don't have to be created all the time

In my head I've always thought that HTTP2 would involve less negotiation (multiplexing?) etc as that would be a bottleneck - IANAExpert

The speed increase from HTTP/2 is partially based on the fact that SSL tickets don't have to be created all the time

But HTTP1.1 also uses session ids, so that's not the point of difference. Q.E.D.

[ghost]

Oh, great idea! Need help with that?

[ghost]

FPI is so powerful, it's one of those most valuable settings. I learned all this here :=)

@Aeriem ,

What we don't know is the actual speed benefits from HTTP/2 when they are disabled,

Which means disabling session IDs has no issue but could have an impact over time on the effectiveness of HTTP/2 enabled speed increase. This is complex.

[Thorin-Oakenpants]

Lets clarify this

HTTP/2 will work without SSL tickets, this is in the specs of the tech, @Thorin-Oakenpants said so and linked some doc to prove it.

I said the HTTP2 spec allowed for unsecure connections (i.e HTTP) but that the major browsers will only support it over secure connections (HTTPS) and what I linked to was wikipedia and it's sources.

I did not link to anything that said HTTP2 in FF works without SSL session tickets. Only Geko said that.

[ghost]

@StanGets I learned so much from this user.js too, it's incredible!

@Thorin-Oakenpants Crappity crap, I said some BS, please don't hit me. T-T Will be more careful next time!

[ghost]

Which means disabling session IDs has no issue but could have an impact on the effectiveness of HTTP/2 enabled speed increase. This is complex.

Exactly! You got it hehe!

[ghost]

Reading your clarification loud and clear, @Thorin-Oakenpants We do remain in a relative expectation.

@Aeriem I had to dig into my sleeping cells!

[ghost]

<+GeKo> Aeriem: yes, they bring speed improvments without ssl session tickets <+GeKo> and, no, they don't require it in the "real world" either <+GeKo> sessions tickets and http/2 are at different levels in the network stack <+GeKo> thus, they are not related/bound to each other

@Thorin-Oakenpants There you go! 😄 @StanGets Me too. O.O

[Thorin-Oakenpants]

I'm still not sure we want to do this. Won't someone think of the polar bears?

[Thorin-Oakenpants]

GeKo i reckon that's gk , or Georg Koppen. Ask him. He's one of the top doggies at Tor. It would help ease my mind that I'm talking to a non peasant

[Thorin-Oakenpants]

@earthlng : what are your thoughts on this proposal. move http2 & AltSrv to an FPI Alts. I'll check what TBB did with the variations of prefs

Edit: TBB 8.0.3, all five prefs are default true

[ghost]

@Thorin-Oakenpants ,

I'm still not sure we want to do this. Won't someone think of the polar bears?

Didn't get the polar bears' allusion but I can understand doubts related to uncertainty.

You had written as well, further above,

I see no problem with making HTTP2 and AltSrv inactive, but session tickets remain a mess.

Indeed. And I read on the Web contradictory comments concerning Session tickets, such as at How's my SSL? where disabling them as I (we) do leads to the site's comment: Session Ticket Support - Improvable followed by a comment on its Session Ticket Support which seems to me incoherent:

Quoting,

However, the session ticket key living on all of the website's computers means there is a secret that could be leaked to an attacker. Worse, it undermines the security of ephemeral key cipher suites.

If so then why does the site consider disabling session tickets as an improvable choice? I don't get it.

[Thorin-Oakenpants]

Man .. now I'm wondering if this requires cookies - https://trac.torproject.org/projects/tor/ticket/14952#comment:51

AltSrv uses DataStorage. This DataStorage_Persistent, DataStorage_Temporary, DataStorage_Private I'm almost certain relates to IDB (but I could be wrong), go look in your profile\storage\ directory

[Thorin-Oakenpants]

@StanGets - ignore that Hows my SSL comment. It's improvable to them only because it improves server load and speeds shit up. I'm sure there were some other benefits. We went thru all this in that other massive thread

Edit: The polar bears reference is from that other massive long thread where it was revealed that the spec isn;t even eco-friendly and in fact chews thru MOAR power, and they could have made it more eco if they wanted, and more private, etc .. earthlng linked to someone's bitchin' kick-ass article on it - I'll dig out the link for ya - here it is, right in the user js with the HTTP2 prefs: https://queue.acm.org/detail.cfm?id=2716278

Edit edit: search #107 for the string "polar bear"

[ghost]

Welp. That's what I thought about... But then again... Deleting ONE (1) (uno) e-mail from your inbox instead of keeping it forever does a lot more for the planet than disabling HTTP/2. Also, many privacy and/or security settings use more power. HTTPS is a problem for the planet, so is SFTP, so is your encrypted password database if you use one, so is using a VPN, so is watching a video, I can go on. :/

Also what should I ask GeKo? He gave us his opinion on the matter, he wants us to enable HTTP/2 and AltSvc. (And SSL tickets but we don't want to.) Also I literally just told him I was finally leaving him alone after bothering him so much. xD

@StanGets The polar bears are @earthlng way of saying that HTTP/2 is bad for the environment. As it uses encryption and multiplexing, it consumes more power, which in turn leads to more CO2. But my answer to that is that almost everything related to security does that, sadly... The most basic example being HTTPS which does exactly what HTTP/2 does... If you want the reference it's in #107

[Thorin-Oakenpants]

crypto currencies dude ... the polar bears have no chance

[Thorin-Oakenpants]

Also I literally just told him I was finally leaving him alone after bothering him so much. xD

I'm just messing with ya. It's clearly Georg Koppen .. GE, KO

[ghost]

@Thorin-Oakenpants ,

AltSrv uses DataStorage. This DataStorage_Persistent, DataStorage_Temporary, DataStorage_Private I'm almost certain relates to IDB (but I could be wrong), go look in your profile\storage\ directory

Nothing new in my IDB storage. I have an application set to react on user chosen modified folders/files (Folder Monitor) and it's set by me to yell when my FF IDB / default gets new visitors. Quiet until now, unless the IDB would get impacted in the temporary section ....

Polar bears, ok. As long as my ignorance was only related to something I hadn't read then it's not problematic :=)

[ghost]

Exactly, this is the perfect example. Every TRUE hacktivist will tell you, cryptomoney is the only way to go if you want to remain anonymous. But just possessing some is harming the environment, let alone PRODUCING some. Think about all the power consumption resulting only from antiviruses running in the background of all the computers in the world. Think about VPNs: they add SO MUCH environmental impact to any basic web search, yet they are the most primal, basic, important and essential tool to just START protecting yourself.

[ghost]

I'm just messing with ya. It's clearly Georg Koppen .. GE, KO

You had me SWEATING, thinking about how he would react if I came back. xDDD

[Thorin-Oakenpants]

You had me SWEATING

Oh jeez .. more climate warming. Thanks a lot Obama

Edit: we're getting a bit OT. Mea culpa. Let's stick to the topic :)

[ghost]

Should I stay or should I go ... (nice song).

As I said, only testing 702 & 703 as commented (disabled). Not sure I keep on testing, no need to be an expert to understand that there is too much uncertainty to consider at this time http/2 and AltSrv as more likely to be viable than not.

[ghost]

Think about PRISM's environmental impact! Mass surveillance is so destructive for the planet, both state and corporate. Maybe corporate even more. Scary...

As I said, only testing 702 & 703 as commented (disabled). Not sure I keep on testing, no need to be an expert to understand that there is too much uncertainty to consider at this time http/2 and AltSrv as more likely to be viable than not.

I disagree! 😮 Both HTTP/2 and AltSvc work perfectly fine and are totally sanitized by FPI. The real mess is SSL Tickets IDs, which we all agreed to keep disabled. I strongly believe we should enable 702 and 703, both for speed and compatibilty, especially given that it is safe, security and privacy-wise.

[ghost]

As a side note, know that I'm stating my ideas because I want to discuss them with you but I am in no way saying I'm absolutely right and trying to force a change onto the user.js! Don't interpret my "strongly believe" as me telling you what to do, I'm just passionately discussing the matter with you! 🤣

This is a template we are trying to design with a particular audience in mind, but I can adapt it to my needs through an override and as such would never try to impose my will onto this super great project!

[ghost]

@Aeriem I'm continuing the testing (702 & 703 commented) but if the price is IDB invasion then i'll know where to revert. Uncertainty doesn't mean I've chosen but only that I'm not as convinced as I was a few lines above. I understand you disagree. I'm practical moreover because i ignore : if i notice speed enhancement and no side-effect such as an impact on my IDB or localStorage then I'll carry on!

[claustromaniac]

I feel fulfilled now.

[ghost]

@StanGets Keep us posted about iDB invasion, it's very interesting!

@claustromaniac Finally! 😄

@Thorin-Oakenpants Don't worry, I'll only feed him more code to crunch.

[ghost]

Not sure if I'm half-on or half-off topic but I have a question regarding TLS settings involving 3 settings available in user.js but not a fourth.

We mentioned above the Session Identifiers complexity. I was searching on this topic and found an article posted Nov 14, 2018, SuperCooKey - A SuperCookie Built Into TLS 1.2 and 1.3

The author describes his research around the impact of TLS 1.3 for Private Internet Access and proposes 4 Firefox settings:

_security.ssl.disable_sessionidentifiers (hidden feature) : we have it at 1203 _security.ssl.enable_falsestart : we don't have it _security.tls.enable_0rttdata : we have it at 1205 privacy.firstparty.isolate : we have it at 4001

security.ssl.enable_false_start by default is true on FF63 at least. I have it true as well.

The author mentions,

[...]we have to disable False Start. This is because it does not allow the client to fully complete its handshake before starting the actual session. There is more info here from the IETF: https://tools.ietf.org/html/rfc7918#section-4 (See section 5. Security Considerations)

Simple question : Should this setting be included and set to false accordingly?

[Thorin-Oakenpants]

@StanGets - see https://github.com/ghacksuserjs/ghacks-user.js/issues/536