Talk:Opportunistic TLS

Layering

Generally a helpful and concise article but the sentence beginning "The style used to specify how to use TLS ..." is awkward. There must be a better description of this concept. Regards, PeterEasthope (talk) 15:45, 29 February 2012 (UTC)

STARTTLS support

I've deleted the claim that Gmail and Apple's iCloud are the only two major free e-mail providers which implement STARTTLS as of 2011. GMX has supported STARTTLS since at least 2005 as shown by a Debian bugreport specifically showing that STARTTLS is supported by GMX. 84.128.88.189 (talk) 05:01, 26 August 2012 (UTC)

STARTTLS preferred to separate ports?

These [separate ports for secure versions of services other than HTTP] are no longer recommended, since STARTTLS makes more efficient use of scarce port numbers and allows simpler device configuration.

Someone marked this as citation needed; I think it's actually wrong because, for example, of downgrade attacks where a network adversary would conceal the STARTTLS capability from the client (pretending that the server didn't offer it). In that case, the client might proceed without encryption. But using a separate port will probably tell clients that TLS is required by policy, so a downgrade attack will fail. Schoen (talk) 02:11, 12 March 2013 (UTC)

Some citations for the first part (scarce ports) of that claim: Section 7 of RFC 2595, section 9 of RFC 6335. But also note section 7.2 of RFC 6335 which indicates a lack of consensus. I would be in favor of replacing the original statement with something like "As of August 2011, while IANA strives to assign only one assigned port number per service or application, there was no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol." and reference RFC 6335. MabryTyson (talk) 00:10, 14 April 2014 (UTC)

Starttls makes it easier for a client to implement a "tls if available" policy than seperate ports do. Such a policy can be both a blessing and a curse depending on the deployment scenario and assumed abilities of the attacker. On the one hand it can help with the chicken and egg situation in a scenario where the main concern is passive attackers. On the other hand if MITM is a concern it can be a hinderace as a client configured for "tls if available" will use encryption normally but can be stopped from doing so by the MITM. 130.88.99.230 (talk) 19:28, 3 November 2014 (UTC)

Recommendation has changed with RFC 8314, preferring separate ports over STARTTLS now. --Exploide (talk) 17:19, 12 February 2019 (UTC)

FTPS is AUTH TLS

According to RFC 4217, cited in the present edition of the article, FTPS uses "AUTH TLS" to start a TLS session, not STARTTLS. Suggest the mention of FTPS be removed or the article changed (renamed?) to be more generic and explain adding SSL/TLS protection to an existing protocol by sending adding an explicit command to turn it on. --192.35.35.35 (talk) 19:05, 28 April 2015 (UTC)

Thanks for leaving this message. I have removed FTPS, at least until we can find a better way to describe it. Best, Tony Tan · talk 19:35, 28 April 2015 (UTC)

LDAP doesn't have a "STARTTLS" command either. Should we rename the article to something like "opportunistic TLS"? Or just strip out the parts about other protocols and concentrate on email? -- intgr [talk] 07:59, 29 April 2015 (UTC)

Moving it "Opportunistic TLS" or a similar name would be a good idea, I think. Tony Tan · talk 17:18, 30 April 2015 (UTC)

Note: Just found that there is already the article opportunistic encryption. Should we just remove the mentions? Tony Tan · talk 03:43, 10 May 2015 (UTC)

@Tony Tan: I have completed the move. I don't understand what you mean by "removing the mentions". -- intgr [talk] 10:40, 31 March 2016 (UTC)

Golden Frog and blocking of STARTTLS

The article says, "In October 2014 VPN provider Golden Frog was found to be doing this using Cisco devices on their network in an attempt to inspect emails and block spam." However, one of the references for that claim actually goes to Golden Frog's website and is titled, "The FCC Must Prevent ISPs From Blocking Encryption" and is about how Golden Frog discovered Cricket Wireless doing the blocking of STARTTLS and how Golden Frog is against this practice. --Onlynone (talk) 15:35, 18 September 2015 (UTC)

Better? Deku-shrub (talk) 23:24, 18 September 2015 (UTC)

I wish I had seen this earlier. It was definitely not better. As far as I can tell Golden Frog and cricket/aio/at&t have never had a corporate relationship and have always been separate entities. It's too bad this incorrect information was live for a year before being removed. The timeline is: Aio Wireless was a subsidiary of AT&T, they started stripping STARTTLS at least by September 2013 when an engineer with Golden Frog first noticed it. In March of 2014 Leap Wireless (parent of Cricket Wireless) was acquired by AT&T. AT&T merged Aio and Cricket into the new Cricket. The new Cricket continued to strip STARTTLS. Golden Frog presented their findings in tech talks and an FCC filing. A TechDirt article was published in October of 2014 based on Golden Frog's findings. I've updated the article with the subtle nuances of the timeline fixed. Onlynone (talk) 16:52, 10 September 2018 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Opportunistic TLS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140610053143/https://starttls.info/ to https://starttls.info/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:13, 20 September 2017 (UTC)

นโยบายความเป็นส่วนตัวทั่วโลกของ SheerID ปรับปรุงล่าสุด: เมษายน 2022 นโยบายความเป็นส่วนตัวนี้อธิบายว่า SheerID, Inc. และบริษัทสาขาและบริษัทในเครือ ( " SheerID ", " we " หรือ " us " ) รวบรวม ใช้ และเปิดเผยข้อมูลเกี่ยวกับคุณอย่างไร เรามุ่งมั่นที่จะปกป้องและเคารพความเป็นส่วนตัวของคุณ นโยบายความเป็นส่วนตัวนี้มีผลบังคับใช้เมื่อคุณใช้เว็บไซต์ของเราและผลิตภัณฑ์และบริการออนไลน์อื่น ๆ ที่เชื่อมโยงกับนโยบายความเป็นส่วนตัวนี้ (เรียกรวมกันว่า “ บริการ ”) ติดต่อทีมบริการลูกค้าของเรา มีส่วนร่วมกับเราบนโซเชียลมีเดีย หรือติดต่อกับเราโดยตรง นโยบายความเป็นส่วนตัวนี้ใช้ไม่ได้กับข้อมูล: (ก) ดำเนินการโดย SheerID ในนามของบริษัทVan Bk Thitikorn Hai..

นโยบายความเป็นส่วนตัวทั่วโลกของ SheerID ปรับปรุงล่าสุด: เมษายน 2022 นโยบายความเป็นส่วนตัวนี้อธิบายว่า SheerID, Inc. และบริษัทสาขาและบริษัทในเครือ ( " SheerID ", " we " หรือ " us " ) รวบรวม ใช้ และเปิดเผยข้อมูลเกี่ยวกับคุณอย่างไร เรามุ่งมั่นที่จะปกป้องและเคารพความเป็นส่วนตัวของคุณ

นโยบายความเป็นส่วนตัวนี้มีผลบังคับใช้เมื่อคุณใช้เว็บไซต์ของเราและผลิตภัณฑ์และบริการออนไลน์อื่น ๆ ที่เชื่อมโยงกับนโยบายความเป็นส่วนตัวนี้ (เรียกรวมกันว่า “ บริการ ”) ติดต่อทีมบริการลูกค้าของเรา มีส่วนร่วมกับเราบนโซเชียลมีเดีย หรือติดต่อกับเราโดยตรง

นโยบายความเป็นส่วนตัวนี้ใช้ไม่ได้กับข้อมูล:

R. ดำเนินการโดย SheerID ในนามของบริษัทMr Thitikorn H EPYAVVYA-SHTMOVYAD 223.24.184.81 (talk) 20:41, 24 November 2022 (UTC)

นโยบายความเป็นส่วนตัวทั่วโลกของ SheerID ปรับปรุงล่าสุด: เมษายน 2022 นโยบายความเป็นส่วนตัวนี้อธิบายว่า SheerID, Inc. และบริษัทสาขาและบริษัทในเครือ ( " SheerID ", " we " หรือ " us " ) รวบรวม ใช้ และเปิดเผยข้อมูลเกี่ยวกับคุณอย่างไร เรามุ่งมั่นที่จะปกป้องและเคารพความเป็นส่วนตัวของคุณ นโยบายความเป็นส่วนตัวนี้มีผลบังคับใช้เมื่อคุณใช้เว็บไซต์ของเราและผลิตภัณฑ์และบริการออนไลน์อื่น ๆ ที่เชื่อมโยงกับนโยบายความเป็นส่วนตัวนี้ (เรียกรวมกันว่า “ บริการ ”) ติดต่อทีมบริการลูกค้าของเรา มีส่วนร่วมกับเราบนโซเชียลมีเดีย หรือติดต่อกับเราโดยตรง นโยบายความเป็นส่วนตัวนี้ใช้ไม่ได้กับข้อมูล: (ก) ดำเนินการโดย SheerID ในนามบริษัทการยืนยันของ SheerID เพื่อยืนยันตัวตนของคุณ

นโยบายความเป็นส่วนตัวทั่วโลกของ SheerID ปรับปรุงล่าสุด: เมษายน 2022 นโยบายความเป็นส่วนตัวนี้อธิบายว่า SheerID, Inc. และบริษัทสาขาและบริษัทในเครือ ( " SheerID ", " we " หรือ " us " ) รวบรวม ใช้ และเปิดเผยข้อมูลเกี่ยวกับคุณอย่างไร เรามุ่งมั่นที่จะปกป้องและเคารพความเป็นส่วนตัวของคุณ

นโยบายความเป็นส่วนตัวนี้มีผลบังคับใช้เมื่อคุณใช้เว็บไซต์ของเราและผลิตภัณฑ์และบริการออนไลน์อื่น ๆ ที่เชื่อมโยงกับนโยบายความเป็นส่วนตัวนี้ (เรียกรวมกันว่า “ บริการ ”) ติดต่อทีมบริการลูกค้าของเรา มีส่วนร่วมกับเราบนโซเชียลมีเดีย หรือติดต่อกับเราโดยตรง

นโยบายความเป็นส่วนตัวนี้ใช้ไม่ได้กับข้อมูล: EPYAVVYA-SHTMOVYAD R. ดำเนินการโดย SheerID ในนามของบริษัท Mr.Thitikorn Haikluean Van 223.24.184.81 (talk) 20:45, 24 November 2022 (UTC)