Accept TLS

[themr0c]

As SSL is deprecated since 2011, we could recommend using TLS rather than SSL/TLS.

https://redhat-documentation.github.io/supplementary-style-guide/#ssl-tls

https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0,_2.0,_and_3.0

[bergerhoffer]

I can't personally vet this, but have no personal objections.

@redhat-documentation/ccs-style-council Does anyone have any good security SMEs that we could run this by before making changes?

[dfitzmau]

I will ask in the JBoss EAP writers group. The latest release of JBoss EAP mentions the use of the SSL/TLS protocol.

[oraNod]

I generally use "SSL/TLS" just because "SSL" is an established term and has more immediacy. Obviously when configuring security protocols you never want to recommend using SSL but TLS v1.2 or v.1.3. When referring to the crypographic protocols I think it should be acceptable to say "SSL/TLS". TLS is also an extension of SSL and not necessarily a completely distinct protocol so the current convention does make sense.

Personally I would advocate for guidance to use SSL/TLS in headings and at a high-level. For steps in procedures or when we talk about enabling/configuring encryption then we should refer to TLS.

[dfitzmau]

I agree with, @oraNod . This topic might not be a clear-cut. I posted a query in the EAP Internal group. This group has over 100 SMEs and some of them work on security components related to the SSL, SSL/TLS, TLS protocol :) . Hopefully, they can reply soon and provide some engineering input.

[dfitzmau]

Hi @themr0c and all. Here's a link to what an engineer on the JBoss EAP said:

Ties in exactly as @oraNod stated. Maybe we could still proceed with this addition and fine-tune the where and when to use such-and-such a term?

[bergerhoffer]

Thanks a lot for posing this question to SMEs @dfitzmau!

Looks like we have a SSL/TLS entry (use it: yes) and an SSL entry (use it: no), but not a TLS entry. Also, the SSL/TLS entry lists "TLS" as an incorrect form.

So if we do want to propose TLS as an appropriate term on it's own, then I think we'd want to:

• Add a TLS entry
• Update the SSL/TLS entry to mention using "SSL/TLS" first, but can use "TLS" alone later
• Remove "TLS" from the incorrect forms list of SSL/TLS

Thoughts?

[stoobie]

@bergerhoffer @oraNod @dfitzmau +1

Thanks a lot for posing this question to SMEs @dfitzmau!

Looks like we have a SSL/TLS entry (use it: yes) and an SSL entry (use it: no), but not a TLS entry. Also, the SSL/TLS entry lists "TLS" as an incorrect form.

So if we do want to propose TLS as an appropriate term on it's own, then I think we'd want to:

* Add a TLS entry

* Update the SSL/TLS entry to mention using "SSL/TLS" first, but can use "TLS" alone later

* Remove "TLS" from the incorrect forms list of SSL/TLS

Thoughts?

[oraNod]

"Update the SSL/TLS entry to mention using "SSL/TLS" first, but can use "TLS" alone later" - On this point I think it would be good to have specific guidance like:

Use SSL/TLS at a high-level, such as in headings and abstracts, to establish context with encryption protocols.

When referring to protocols that you use to exchange cryptographic keys and secure network communication or other system in any procedure, always refer to TLS and recommend using the most recent versions of the TLS protocol as well as cryptographic algorithms.

---

The second point is especially important and should be reviewed with any SME when in doubt. I think it is extremely important that our documentation never recommends weak or out of date encryption protocols because that has the potential to lead to security breaches. Consider the case where a user system gets hacked due to a weak TLS version (v1.1) but our documentation suggested using it.

[emarcusRH]

from my experience in the Cyber Security world (5 1/2 years), TLS is the term that should be used - it is the more advanced or newer form of the SSL protocol. When one is looking to see what the supported or required security protocol is, TLS + version number is the standard these days. see this article - TLS vs SSL

[dfitzmau]

+1 Don's suggestion that ties in with the SME feedback.

[bergerhoffer]

@dfitzmau Any chance you would be up for proposing a PR for this issue since you had already connected with an EAP SME on the issue? Definitely seems like something we should get some more SME feedback on before making a decision.

@bburt-rh was also going to be looking for some security SMEs for the other issue, so maybe you could combine efforts to get multiple security questions to the same SMEs?

Sounds like TLS might really be the appropriate term, but it's possible that keeping "SSL/TLS" (for findability reasons) might be worthwhile. But we'd need to make sure with SMEs that we aren't being inaccurate in doing so.

[dfitzmau]

Hi @bergerhoffer . I'll look into this on Friday, but I would be writing content from the perspective of JBoss EAP and perhaps the Runtimes team.

Does the status of this Issue need to change?

[bergerhoffer]

Thanks @dfitzmau! I added you as an assignee to this issue. That's fine to get the perspective of EAP's team, but it would probably be a good idea to contact SME(s) from other areas as well, to be sure. I'm not sure who else to suggest though.

[dfitzmau]

I'll focus on JBoss EAP and maybe the runtimes team; anything outside this might be too much work in regards to chasing down who specializes in what on what product.

[bburt-rh]

I'll see what else I can find out.

[mportman12]

Closing this issue because the PR has been merged.