Talk:HTTPS/Archive 1

Archive 1

To do

To do:

• mention the virtual hosting IP address problem: how does SSL/TLS know which cert to present?
• mention the HTTP to SHTTP boosting solution: but not yet widely deployed

The Anome 17:46 Feb 24, 2003 (UTC)

I came here looking for how to write web pages that use HTTPS. Is there an HTML keyword? Did not get any help. Would be nice if there was a pointer to that information.

HTML and HTTP are two different things. HTML is a markup language and HTTP is a protocol which can be used to transport html to a web browser. Your HTML will not look any different whether being transported via HTTP or HTTPS.

I don't have a pointer but no, it doesn't depend on HTML. The client can initiate HTTPS by using an https: URL, and/or you can configure virtual directories on your Web server to require HTTPS. Yaron 20:45, May 17, 2005 (UTC)

Different types of SSL certificates

I'd love to see a discussion of this, as as far as I can tell, the different options (primiarly upsells from the base certificate) are pretty much a hoax. wildcard dns can be useful, but otherwise arguments by companies that SGC or org-validated certificates will be more secure seem unlikely - the SSL is either going to be encrypted at 128 bits or not. https://www.servertastic.com/ssl-certificates/

The point of the servers SSL certificate is to ensure that the server you are talking to is in fact the server you think you are talking to. Some certificate types have better checking of the applicants claims than others and so provide a greater confidence of this. Unfortunately this information is only of use if it's communicated to the user which is something browsers have traditionally been bad at (though i've noticed firefox is now displaying company names in the address bar for some certificate types). Plugwash (talk) 23:55, 13 September 2009 (UTC)

Name-based virtual hosting

The article says:

(This is subject to change in the upcoming TLS 1.1, which will enable name-based virtual hosting. As of December 2006, all major web browsers support TLS's Server Name Indication feature, but the feature is not widely used by web sites.)

However, there are no details nor pointers on this subject. Either one would be appreciated. -- Ernstdehaan 14:29, 16 May 2007 (UTC)

This article now gives some details and the Server Name Indication article gives more.Afaict the bottom line is that the built in SSL support on XP doesn't support SNI so any browser that relies on windows SSL support won't support SNI on XP. Therefore until use of internet explorer, safari and google chrome on XP dies out (not coming any time soon) this feature can't really be used. Plugwash (talk) 13:38, 15 September 2009 (UTC)

Adecco website redirects here!

Why does this page keep coming up every time I access a Job registration page? I dont give a hoot about https; get the thing off.

Because Adecco's web coders are morons. If you're using Firefox, it gives you this page instead of their application form for some weird reason.

If you type just "https" (or any other non-url) into your URL bar in firefox, firefox types it into the search at google.com and presses the I'm feeling lucky button, which takes you to the first match of the search. Google's first match for "https" is the wikipedia page, so you are redirected there. Adecco must have made a mistake in their link coding to cause this. Blame them, not wikipedia. Rjmunro 15:46, 15 September 2006 (UTC)

Can't view this article

I can't view the article directly from here, as it gives me the "Wikipedia does not have an article with this exact name" box. I can, however view it through it's history by looking at the diff between the current version and the last one. --Sivius ^T-C 20:59, 17 September 2006 (UTC)

Not reproducible. -- Ernstdehaan 14:30, 16 May 2007 (UTC)

Out-of-place text that I cannot delete

I see the following text on a separate line just below the first paragraph of this article:

sales assistant where house security

I tried to edit the article, to get rid of it, but it doesn't appear on the "edit this page" page. Maybe if someone else knows how, they could clean it up. Thanks. —The preceding unsigned comment was added by 75.5.96.236 (talk) 00:05, 16 February 2007 (UTC).

UPDATE - Nevermind. Somebody took care of it, and I was still seeing it. A friend clued me in to "control-r", which refreshed the bogus text out of existence.

Diagram & How It REALLY Works?

It would be great to see a state diagram of how the secure connection is made and at which point the HTTP request is actually sent to the server. The current "How It Works" section really doesn't describe it very well. --Lance E Sloan 19:40, 26 February 2007 (UTC)

Well, the article does say that https is just an use of the SSL/TLS protocol. How TLS works is explained on that article, at Transport Layer Security#How it works. Was this more useful? Any ideas how to make it more obvious? (I've currently added a "for details, see ..." link to the article) -- intgr 20:21, 26 February 2007 (UTC)

Someone please add a sequence diagram for communications over HTTPS. A simple diagram should do. ddas|edEn (talk) 08:32, 4 March 2008 (UTC)

difference between SFTP & HTTPS

What are the differences between SFTP & HTTPS? —The preceding unsigned comment was added by 15.227.137.71 (talk) 10:36, 15 March 2007 (UTC).

It is the same difference as FTP & HTTP, only now they are bot secure. HTTP is used for visiting websites, FTP is a file transfer protocol. 213.73.219.133 09:19, 18 May 2007 (UTC)

Actually, I think SFTP uses a different underlying protocol. 171.71.37.29 20:29, 4 October 2007 (UTC)

sftp != ftps, ftps is ftp over ssl just like https is http over ssl. sftp is a system for transfering files over a ssh session. Plugwash 22:42, 4 October 2007 (UTC)

External Link Proposal

Why are the bottom 4 links in the following list considered spam? I checked each one of them individually and they all appear to be well-suited..

Spam links?

• MSDN documentation of the Secure Channel API
• SSL Introductory Tutorial

What do you think? Any of these a good match for this page? I'm still a newbie so..

Produke 22:59, 25 March 2007 (UTC)

HTPS redirect

Why does HTPS redirect here? I was hoping to find more information about a display technology in LCD projectors. 194.7.161.130 08:22, 4 September 2007 (UTC)

Obviously it's a misspelling of "HTTPS"; it wouldn't interfere with the creation of an article about HTPS, just nobody has written it yet. -- intgr ^#%@! 11:54, 4 September 2007 (UTC)

Wrong spelling https:gmail.com Binky5167 (talk) 02:09, 27 August 2020 (UTC)

vs Comcast

A lesser-known effect of Comcast's traffic shaping is that they completely block incoming http requests (i.e. they apparently regard http servers as being worse than torrents). Does https obfuscate the http request so that Comcast treats the packets the same as they would for other protocols? Ham Pastrami (talk) 11:26, 19 February 2008 (UTC)

Capitalization

Why does the HTTP article capitalize the abbreviation while this article lower-cases the HTTPS abbreviation? I would have expected the abbreviation to be all uppercase when used as a word and all lowercase when used as a protocol-prefix (i.e, when the colon follows it), i.e., HTTPS vs. https:.

-Andreas Toth (talk) 22:06, 19 February 2008 (UTC)

The short version: http and https are protocol identifiers. HTTP is a protocol. HTTPS doesn't exist. The long version: in Netscape's original specification for SSL and related RFCs, "https" is only used in the context of a URI. The protocol itself is usually referred to as "HTTP over SSL" or "HTTP/SSL". In modern context the actual protocol being used is just as likely to be HTTP/TLS. "https" is merely a mnemonic chosen for security-enhanced HTTP. The actual protocol used to implement enhanced security is subject to change. Netscape could just as easily have chosen "asdf://" to signify HTTP/SSL and then this answer might be better understood, though the identifier wouldn't be! Ham Pastrami (talk) 02:07, 20 February 2008 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was move. JPG-GR (talk) 05:54, 19 August 2008 (UTC)

Hypertext Transfer Protocol over Secure Socket Layer → https — I'm requesting to rename this article back to "https", like it used to be until May 2008, when User:Ziggymarley01 moved it to its current name. This move was done without sufficient prior discussion and contrary to WP:COMMONNAME; people rarely write out "Hypertext Transfer Protocol", much less when referring to the secured variant. Furthermore, Secure Sockets Layer has been deprecated, and RFC 2818 actually calls this protocol "HTTP over TLS".

Alternatives also include "HTTP/TLS" or "HTTP over TLS", although I am leaning towards https. — -- intgr [talk] 11:50, 12 August 2008 (UTC)

Survey

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's naming conventions.

• Oppose Regardless, every other page on the TCP/IP model infobox follows this convention. Such a discussion should take place for all at once, having one oddball is bad for consistency. ffm 17:02, 12 August 2008 (UTC)

  WP:COMMONNAME is defined as "Use the most common name of a person or thing that does not conflict with the names of other people or things", so I can't see how you could not decide this on a case-by-case basis. The acronyms TCP and UDP are ambiguous whereas "https" is not.

  I don't think that consistency of infoboxes has any precedence over established Wikipedia naming conventions. You'll also note that this article is not actually present on the "TCP/IP model" infobox. -- intgr [talk] 20:05, 12 August 2008 (UTC)

Discussion

Any additional comments:

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Article name

I can't believe I'm the only one who noticed that the name of this article contains a misspelling. Protocal? Really?? --Simon Wright (talk) 03:57, 4 December 2008 (UTC)

Fixed. -- Rick Block (talk) 18:43, 4 December 2008 (UTC)

Man-in-the-middle attacks

I've just removed a few sentences claiming that HTTPS wasn't secure against man-in-the-middle attacks, because they were incorrect. There are cases where MiM attacks may occur if the cipher suites are not appropriate (e.g. anonymous ones), but otherwise, that's the point of SSL. I've also removed this sentence "https only protects data in transit from eavesdropping and not man-in-the-middle attacks. Once data arrives at its destination, it is only as safe as the computer it is on. Gene Spafford states that it is like "using an armored truck to transport rolls of pennies between someone on a park bench and someone doing business from a cardboard box."[2]". If a man controls your computer, he's no longer in the middle: that's not a MiM attack. This quote from Gene Spafford seems out of context, since SSL/TLS allows the client to check the identity of the server it's talking to by checking its certificate (how it trusts it is a distinct issue).

I've left the last part about the static and publicly available content, but the explanations are a bit simplistic, I think. This really only leads to a guess as to what the downloaded page may be and that guess is only realistic if the eavesdropper knows the entire possible set of webpages the server may return (or as much as possible). —Preceding unsigned comment added by BrunoHarbulot (talk • contribs) 03:56, 10 December 2008 (UTC)

I agree with the removal of content. If the decision is to keep the material involving possessing the cipher and plaintext, we should link to Chosen-ciphertext attack, I will add this. Otherwise, someone has no way to know what is the problem with having a cipher text and plaintext pair for an unknown key. --Chrismiceli (talk) 22:15, 16 July 2009 (UTC)

It appears that a certain type of man-in-the-middle attack is possible see [1]. I found that reference in the French-language Wikipedia article on HTTPS. Does anybody object to my adding this reference in the Limitions section?--Gautier lebon (talk) 07:07, 10 June 2011 (UTC)

Suggestion: rename this article

Given the availability of the (newer) Transport Layer Security (TLS) as an alternative to Secure Socket Layer (SSL) protocol, why don't we rename this article "HTTPS" or "Hypertext Transfer Protocol Secure"?

Recent additions to this article prompt reconsideration of this matter, which was introduced in earlier posts below.

WorldlyWebster (talk) 13:48, 25 December 2008 (UTC)

Missing Redirect?

Hypertext Transfer Protocol Secure does not redirect to this article. The article starts out with those exact words in bold. I'd suggest that someone creates the redirect (I cannot) or change the first words to HTTPS ("Hypertext Transfer Protocol Secure"). 75.71.216.105 (talk)

Thanks, redirect created. -- intgr [talk] 21:10, 25 June 2009 (UTC)

Performance

What are the performance implications of https? ··gracefool☺ 08:32, 4 July 2009 (UTC)

https - example link

Hi, I was just trying to see whether my server would read an HTTPS document, and thought - lets find an https document on the web. And ... you know how things are there when you don't need them and when you start looking!

This note is just to let you know that this was the first https document I could find, - I looked down the list on https on wikipedia and this was the only link to an https URL so I used it as a "test to see if https" was working (and from the way it still says: "loading ..." I suspect not!

79.79.255.151 (talk) 08:29, 22 September 2009 (UTC)

https - example link

Hi, I was just trying to see whether my server would read an HTTPS document, and thought - lets find an https document on the web and try. And ... you know how things are there when you don't need them and when you start looking!

This note is just to let you know that the first https document I could find was a single link at the bottom of the "see also" list - not exactly an "example" - so I used it as a "test to see if https" was working (and from the way it still says: "loading ..." I suspect not!

But surely there must be a better "test page" for https?

Oh, *******, it appears that this page is available both from an http: and an https: protocol link, so it is hardly the best example of a "test" https page, because, even if it does return with a result, I wouldn't know for sure it it were the http or https protocol that was giving me the page.

79.79.255.151 (talk) 08:31, 22 September 2009 (UTC)

Could you use socks as a proxy? Slowmotion82 (talk) 02:55, 15 May 2022 (UTC)

How can fix the error 105.234.166.26 (talk) 10:47, 22 May 2023 (UTC)

Attacks against HTTPS

There should be a section about real life attacks against HTTPS including:

• Similar looking domain names (Cyrillic 'a')
• The null character bug in domain names.
• Dodgy CAs allowing anyone to buy any certificate.
• MitM HTTPS-stripping and hoping the user doesn't notice.

93.97.48.217 (talk) 10:35, 31 October 2010 (UTC)

Indeed, the certificates help only robots, who connect to hardcoded links. Https adds almost no value to TLS in this case since hypertext it built on top of transport layer for human clicking the hyperlinks. Human are ease victim of phishing. There is even no need to replace Latin letters with corresponding Russian ones -- the average user will eat absolutely bullshit-looking URL. Now, how do we connect only to good sites? By prefixing malicious ones with https and certifying them! Here is an example http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html Seeing that a website is secure and certified, user will more easily give up his passwords. Right? Hardly such "increase of confidence" improves our security. Perhaps, the international community is just too busy building their doors that it does not mention lack of walls around, so Wikipedia should not care either? --Javalenok (talk) 15:10, 11 April 2012 (UTC)

See also link

There is an "see also" link to why. However, there is nothing on that (huge) disambiguation page that looks like the possibly intended target page. — Preceding unsigned comment added by 135.196.150.2 (talk) 20:55, 20 June 2011 (UTC)

interposing intermediary that terminates the HTTPS connection on behalf of the site

What does this actually mean to the end user? Some clarification would be nice Mayhaymate (talk) 10:15, 30 May 2012 (UTC)

"Limitations" section

http://en.wikipedia.org/wiki/HTTP_Secure#Limitations has {{cleanup|section|date=April 2010}}. I propose that this section is now fine, the only problem I can identify being that the points in "From an architectural point of view" could use some references. --AlastairIrvine (talk) 03:50, 3 August 2012 (UTC)

URL encryption

Regarding "Everything in the HTTPS message is encrypted, including the headers, and the request/response load.", it still is ambiguous to me: is the URL (especially the path and the parameters part) encrypted OR not; could you state that explicitely in the text please, Thank you, --AlainR345^{Techno-Wiki-Geek} 22:38, 26 June 2013 (UTC)

Yes, as far as I know, the path is a part of the payload. So if you go to

https://en.wikipedia.org/wiki/HTTP_Secure#Network_layers

The blue part is encrypted. The DNS request and the server you're contacting is usually available. The orange part isn't sent to the server at all, unless there is a separate script in the page explicitly sending it to the server.

See here. --BurritoBazooka (talk) 23:14, 26 June 2013 (UTC)

SSL/TLS or TLS/SSL

Is it SSL/TLS or TLS/SSL? In this article both ways are used but so it is in http://en.wikipedia.org/wiki/Transport_Layer_Security.

This RFC only mentions "SSL/TLS". Usually the RFCs define what is 'official'. "SSL/TLS" makes more sense because it is in kind of a chronological order, similar to GNU/Linux. GNU came first, and parts of GNU and other software was used to build many Linux distros. --BurritoBazooka (talk) 01:29, 27 July 2013 (UTC)

Maybe the way could be uniform. — Preceding unsigned comment added by 217.112.249.71 (talk) 08:08, 17 July 2013 (UTC)

How do I turn it off?

I have had https enabled for some time. I do not know how it turned on, but I really would like to turn it off. Does anyone know how? Nicholasemjohnson (talk) 23:59, 11 September 2013 (UTC)

If you are asking about Wikipedia, there are two pages you should be aware of. WP:HELPDESK handles how-to issues, and WP:VPT handles tricky technical questions. Searching VPT will probably find some of the several recent threads on the subject. Johnuniq (talk) 01:23, 12 September 2013 (UTC)

sslsniff should be mentioned?

Another attack tool had been presented on BlackHat 09: http://www.thoughtcrime.org/software/sslsniff/. Article doesn't mention about it at all. It signs https connection with derived (fake) certificate. Video here http://www.thoughtcrime.org/software/sslstrip/ says "You'd be surprised who still doesn't check basic constraints." So has this been fixed in all browsers now? Should the an article mentions it as well? Yurivict (talk) 09:18, 5 January 2014 (UTC)

Probably not, sslsniff is just one out of tens of https MITM proxies out there. The attacks it uses should be documented on relevant articles, not necessarily here. The null byte attack is already covered in Transport Layer Security -- intgr [talk] 22:27, 5 January 2014 (UTC)

Article doesn't quantify the dangers of using https. Many people (are taught to) trust https almost unconditionally. However it had been broken (or still is broken) on many occasions. The video that I linked to implies it had been fairly recently broken in that way, and many browsers weren't checking constraints. I think that if any of those attacks still work in major browsers this should be prominently explained here in https article. And MITM can be very easily done in some common environments, like open WiFi one. I just can't find any references confirming that lack of certificate constraint checking (exploited by sslsniff) is patched in major browsers. Yurivict (talk) 23:36, 5 January 2014 (UTC)

Browser vulnerabilities are patched very quickly, browser vendors do take security seriously. There is no chance such a critical vulnerability would remain in browsers for 4 years (well, except I guess in Internet Explorer 6).

You can't do MITM against https in general, unless the user explicitly accepts a rogue CA or website certificate. Depends on whether you consider that "easily done", but I wouldn't say it's a vulnerability of https. Even the "lock icon favicon" user interface problems abused by sslstrip have been improved. -- intgr [talk] 15:12, 6 January 2014 (UTC)

Requested move 18 February 2015

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved per request. Favonian (talk) 20:53, 25 February 2015 (UTC)

---

HTTP Secure → HTTPS – Per WP:COMMONNAME and actual usage (including in the article itself: never referred to as HTTP Secure; also see Google Ngrams, which show HTTPS around 50 times higher than what it stands for or HTTP Secure), HTTPS would be a much better title for this – — Mini-Geek ^(talk) 20:53, 18 February 2015 (UTC)

This is a contested technical request (permalink). Steel1943 (talk) 22:34, 18 February 2015 (UTC)

• This is inherently controversial since a policy that could be agreed or disagreed on (WP:COMMONNAME) was stated as a "technical reason". Steel1943 (talk) 22:34, 18 February 2015 (UTC)

• Oppose the proposed new title, but do believe the article should be moved. I'm thinking that it may make more sense for this article to be placed at its most technical name, which seems to be Hypertext Transfer Protocol Secure. Steel1943 (talk) 22:34, 18 February 2015 (UTC)
  • Best as I can tell, the official name (if there is one) is "HTTP over TLS". The URI scheme is "https", which is borrowed from prior schemes and combines the previously-existing "http" with an "s" to indicate "secure", but without officially meaning "Hypertext Transfer Protocol Secure". I'm guessing that's some sort of backronym that stuck. Thus, Hypertext Transfer Protocol Secure is neither the technical name, nor the common name, but an expansion of the common acronym. I oppose it being moved *there*. — Mini-Geek ^(talk) 19:39, 23 February 2015 (UTC)
• Move to Hypertext Transfer Protocol Secure per Steel1943 --CookieMonster755 (talk) 00:56, 19 February 2015 (UTC)
• Move to HTTPS per WP:COMMONNAME. The acronym is far more recognizable because people see it every day in their browser address bar. "Hypertext Transfer Protocol Secure" isn't even an official expansion of the acronym — the RFC is called "HTTP Over TLS". And Google test prefers HTTPS by a ratio of 6000. -- intgr [talk] 08:45, 19 February 2015 (UTC)
• Move to HTTPS per intgr: the current name is a neologism as "HTTP Over TLS" would seem to be the technically correct name per the RFC, but that name is awkward and rarely if ever used. HTTPS seems to be more commonly used (e.g. the EFF's "HTTPS Everywhere" project). —Ruud 10:53, 19 February 2015 (UTC)
• Strong support per nom Red Slash 19:38, 19 February 2015 (UTC)
• Support: Contrary to @Steel1943:, WP:COMMONNAME trumps "most technically correct name" on Wikipedia. Wikipedia prefers the name that is most commonly used (as determined by its prevalence in reliable English-language sources) as such names will be the most recognizable and the most natural. "HTTP Secure" is a peculiar choice though I understand how it probably was chosen. —EncMstr (talk) 20:29, 19 February 2015 (UTC)

• In this case, I really do not see the basis for moving this article to HTTPS. I compare this to File Transfer Protocol; the full name assists readers in knowing what the term represents when they arrive at the article. Steel1943 (talk) 21:08, 19 February 2015 (UTC)

@Steel1943: In the case of FTP there is no dispute that the acronym stands for "File Transfer Protocol". It is not clear, however, that HTTPS is an acronym of "Hypertext Transfer Protocol Secure", I at least haven't seen a reference to support this. (In fact, I believe that HTTPS is a recursive acronym that stands for "HTTP over SSL", or "Hypertext Transfer Protocol over Secure Sockets Layer" in full). —Ruud 12:52, 20 February 2015 (UTC)

• Support per WP:COMMONNAME. Zarcadia (talk) 20:52, 23 February 2015 (UTC)
• Support move to HTTPS per WP:COMMONNAME Tony Tan⁹⁸ · talk 22:29, 23 February 2015 (UTC)
• Weak support: HTTPS is certainly the common name, and the jury's certainly out on whether or not "HTTP Secure" even exists as a name (I certainly never saw it until a couple months ago here on Wikipedia, and I work as a web dev). Still, part of me thinks that a more descriptive name should be used rather than just the HTTPS acronym. // coldacid (talk|contrib) 03:27, 25 February 2015 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Discussion at Village Pump (Proposals)

There is a proposal to enable HTTPS by default for all readers on Wikipedia at the Village Pump. Your input in the discussion would be welcome. Thank you, Tony Tan⁹⁸ · talk 03:39, 20 February 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on HTTPS. 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/20090526233211/http://www.mozilla.com/en-US/legal/privacy/firefox-en.html to https://www.mozilla.com/en-US/legal/privacy/firefox-en.html
• Added archive https://web.archive.org/web/20090308103611/http://sysd.org/stas/node/220 to http://sysd.org/stas/node/220

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: 5 June 2024).

• 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) 15:09, 27 October 2017 (UTC)

Requested move 9 October 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: no consensus to move. Fairly strong agreement that the WP:COMMONNAME policy favors the current title. Moving the Hypertext Transfer Protocol article, as suggested, would require a separate discussion. Favonian (talk) 15:15, 16 October 2018 (UTC)

---

HTTPS → Hypertext Transfer Protocol Secure – Articles should use the subject's formal name for their title, not an abbreviation. Zoms101 (talk) 15:22, 9 October 2018 (UTC)

This is a contested technical request (permalink). Hhkohh (talk) 16:46, 9 October 2018 (UTC)

@Zoms101: I am afraid WP:COMMONNAME dictates that we should use the common name as the article title, which—in this instance—is HTTPS, by far. Regards, SshibumXZ (talk · contribs). 15:33, 9 October 2018 (UTC)

There is no reasonable way this could be considered uncontroversial. — Frayæ (Talk/Spjall) 15:33, 9 October 2018 (UTC)

@SshibumXZ: Thanks for your input. I noticed that the article for HTTP (Hypertext Transfer Protocol) used its full name, so I figured HTTPS should follow the same format. Maybe HTTP should be changed? Zoms101 (talk) 16:29, 9 October 2018 (UTC)

It would certainly make sense that they would both use the same title format. 142.160.89.97 (talk) 16:36, 9 October 2018 (UTC)

@142.160.89.97: As well their display titles. Zoms101 (talk) 16:44, 9 October 2018 (UTC)

• Comment: I don't have an answer yet, but both HTTP and HTTPS should be written the same. I can't see any valid reason for them using different styles. --Gonnym (talk) 17:49, 9 October 2018 (UTC)

Out of all the links in Template:IPstack, only 5 are using abbreviations (HTTPS, MQTT, XMPP, IPv4, IPv6), while "famous" ones such as DNS (Domain Name System), FTP (File Transfer Protocol), SSH (Secure Shell), TCP (Transmission Control Protocol), IP (Internet Protocol) and others, use the full title. It seems there is a pretty clear naming convention here. I'll support this if no new information turns up. --Gonnym (talk) 17:56, 9 October 2018 (UTC)

• Support – Gonnym has demonstrated that we have a naming convention here and it only makes sense that we would use the same title format for our articles about HTTP and HTTPS. 142.160.89.97 (talk) 19:09, 9 October 2018 (UTC)
• Support – per Gonnym. Neodop (talk) 19:22, 9 October 2018 (UTC)
• Oppose. I think WP:COMMONNAME applies here, and the common name is HTTPS. I think the other articles mentioned as counter examples should be moved. Rreagan007 (talk) 20:46, 10 October 2018 (UTC)
• Oppose. Very difficult to Google but my kneejerk is that the full name is spelled out very rarely, even more rarely than HTTP is spelled out, so there may actually be some cause for one to be at the abbreviation and the other not. THat said, if we DID have to make them consistent, I'd be more inclined to move HTTP to HTTP than move this article to Hypertext Transfer Protocol Secure. SnowFire (talk) 22:59, 10 October 2018 (UTC)
• Oppose per COMMONNAME. CookieMonster755✉ 01:16, 11 October 2018 (UTC)
• Oppose per WP:COMMONNAME. -- The Anome (talk) 13:38, 11 October 2018 (UTC)
• Oppose HTTPS is the common name; I have never seen this spelled out entirely (and can't find any RFCs or the like that do so). We don't always spell out acronyms in titles, and we don't need this to be consistent with HTTP. power~enwiki (π, ν) 21:02, 11 October 2018 (UTC)
• Oppose move per COMMONNAME. ONR (talk) 23:56, 11 October 2018 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

"Not secure" listed at Redirects for discussion

A discussion is taking place as to whether the redirect Not secure should be deleted, kept, or retargeted. It will be discussed at Wikipedia:Redirects for discussion/Log/2020 March 25#Not secure until a consensus is reached, and readers of this page are welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines. Utopes _{(talk / cont)} 15:06, 25 March 2020 (UTC)

dead reference link, recommending removal or replacement

Reference link 2 : " "What is HTTPS?". Comodo CA Limited. Archived from the original on 2015-02-12. Retrieved 2018-10-20. Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...]" (link: https://www.instantssl.com/ssl-certificate-products/https.html) is dead and redirects to a portal offering payment schemes. I would like to recommend it is replaced with a link that performs a similar function. 79.73.208.74 (talk) 09:08, 9 November 2020 (UTC)

Adoption or History/Adoption section?

The adoption of the HTTPS protocol experienced moments of growth that can be explained by the systematic adoption:

• the slow and continuous growth of e-commerce;
• explosive growth after 2013, with the revelations, as reaction to global surveillance;
• growth with the breaking of cost barriers at web-servers, starting in 2016 as a "second wave of reaction", as showed by for example https://letsencrypt.org/stats/

The statistical of the protocol and some correlations, is a evidence-based way to show history and adoption.

Krauss (talk) 09:31, 21 May 2021 (UTC)