The true meaning of 'https://' RRS feed

  • Question

  • User-2080516833 posted

    This is a question regarding the true meaning of 'https://' when it is displayed in the browser address bar.

    We have an IIS6 web site on a Windows 2003 server which is configured to use SSL on port 443 and 128bit encryption and which is "secured" with a self-signed certificate that has EXPIRED. When the web site is accessed via a browser with a URL beginning 'https://', the browser throws up error messages about the expired certificate - which is to be expected. You can however accept the certificate and proceed to browse the web site during which time the browser always shows site page URLs with an 'https://' prefix.

    The question is: even though the certificate is EXPIRED, are the exchanges between the server and the browser still encrypted by SSL?

    It certainly look’s that way because the browser URLs have the 'https://' prefix. If it is not, and the data is not securely encrypted, presumably it means the same as 'http://'; in which case the question is: why doesn’t the browser show this?

    Thanks to anyone who comments.

    Friday, July 15, 2011 12:54 PM

All replies

  • User1073881637 posted
    Yes, traffic is still encrypted, just the cert is expired and the browser is warning you.  The expected results from a browser is to use a trusted certificate from a trusted source, not expired. 
    Sunday, July 17, 2011 7:46 PM
  • User1548395086 posted

    HTTPS Works by the server sending a Certificate to the browser, which the browser verifies with a third party. in your case this fails because the certificate fails (as you said).

    however you can override the warnings and self verify the certificate yourself. The browser says "OK" and proceeds as if the certificate was completely valid. There are absolutely no differences in the encryption of the communications


    Wednesday, July 20, 2011 11:44 PM
  • User-2080516833 posted

    Thank you all for your comments but at the risk of sounding ungrateful, is there a way to garner evidence to prove the data is encrypted when a certificate is expired?

    Tuesday, August 23, 2011 12:45 PM
  • User1073881637 posted
    use network monitor or a network packet sniffing software like wireshark.
    Tuesday, August 23, 2011 2:19 PM
  • User-2080516833 posted

    Thanks Steve. Given your answer, I obviously asked the wrong question. It may have been better mentioned at the outset but what I am seeking are irrefutable reasons why encryption is guaranteed regardless of the state of the certificate; and expressed in terms people at Management level can accept and understand, and who mistakenly believe the contrary.

    Wednesday, August 24, 2011 11:59 AM
  • User-2064283741 posted

     Well like steve said just look at the traffic. Does it encrypt the data or can you read it in plan text?

    However do you have a cert that has expired and you don't want to renew it? Why do you want to do that? If it is public faciing, browsers not teh server, can throw up a warning and that will not look good and enter a stage of no/low confidence for your site.

    Wednesday, August 24, 2011 12:27 PM
  • User-2080516833 posted

    Precisely Rovastar. It is often expedient to use a temporary certificate - or certificates may just expire - but most people will accept this provided they feel confident their data continues to be encrypted. The issue is therefore to inspire this confidence… ideally by way of explanation rather than demonstration as inviting people at Management level to take a look at the data is asking to be shown the door.

    I had not noticed it earlier, but the discussion at http://stackoverflow.com/questions/5810993/expired-ssl-certificate-and-encryption is along the lines I was after.

    Thursday, August 25, 2011 2:07 PM
  • User1073881637 posted
    You are asking a pretty open ended question and expecting us to say with 100% confident stuff is safe.  Generally, to prove something is right they need to see it for themselves.   If people who are using the site are non-technical, they'll just proceed assuming an error.  I've seen sites where they ask for sensative data w/o a certificate, because they don't know any better.  If the person is technical in nature, they'll be a better judge of determining if a site is safe or not.  If someone in my family asks if they should ignore this error, I tell them to not proceed because it could be a phishing site.  If your audience is developers and a self-signed cert is sufficient, using them is ok.  Depends on the use case. 
    Thursday, August 25, 2011 8:45 PM
  • User-2064283741 posted


    If your audience is developers and a self-signed cert is sufficient, using them is ok.  Depends on the use case. 

     I think no audience is exempt from a signed valid SSL cert. Some users will not want this even in IT, Would I feel confidence advising a client to buy useful and time saving software for say, moving and compacting IIS logs around the server estate, if they didn't have a valid SSL cert when ordering on the site?

    a self signed SSL cert will only lose some customers, how many hard to say, you could look at your logs to see who bails out when they get to that page, but if it is 1% why do you want to stop those purchasing (SSL is needed for purchasing so this is the example obviously all sensitive info should have SSL) your goods/want to make transactions?

     Cost is the only issue, with the price of the SSL signed cert versus how much you lose in sales or potential/future sales, (you will not gain sales from a self served cert), your reputation by some/few that notice this, lack of professionalism, who knows what a browser might say in the future to handle their was much tech talk when Firefox changed their expired SSL warning to a more ugly/threatening one, it is all out of your control, etc, etc

    Surely it not too hard to convince business of this.

     As for the security questions, it as Steve suggests, is open ended. The question could be even, which is safer Signed SSLs or self SSLs? I am no experts but I would suggest, if i had to choose one is better/safer than the other, it would always be the sign one. Could there be some crazy man-in-the-middle attack just for self SSLs......dunno

    I personally would never recommend not using signed SSLs on public facing sites (increasingly Intranet/internal sites are becoming SSL and the need for separate signed certs, sometimes wildcard certs are not desired even. Had this discussion recently; do we want hundreds or thousands of site with subdomians for *.mysite.com, all around the world, that different teams manage and are core to the business so they can work to all be renewed on the same day when the SSL cert runs out in the future?)

    Friday, August 26, 2011 1:18 PM
  • User-2080516833 posted

    Thanks to all. But I cannot agree the question is open ended as it requires just factual support of answers already given (presumably with 100% confidence). Also, the Use Case is academic if users are not permitted access to the site by Management believing the data to be unencrypted - and who are not dissuaded by marks of the nails, being astute enough to realise they do not know what a nail is.

    If it were set as an MCPD question, I wonder what the model answer would be.

    Tuesday, August 30, 2011 10:54 AM
  • User-1672167363 posted

    Hello All,

    The companion Thread http://forums.iis.net/t/1179995.aspx is open

     Your requirements are facts rather than tools or methods.

    Thank you for all the replies and answers. 




    Tuesday, August 30, 2011 11:16 AM
  • User-2080516833 posted

    Thanks HCamper: but just to clarify, what I’m actually seeking are facts rather than tools or methods.

    Also, I’m not sure why the companion thread at http://forums.iis.net/t/1179995.aspx is still open.

    Tuesday, September 6, 2011 10:42 AM
  • User-1672167363 posted


    Your requirements are facts rather than tools or methods.

    The companion thread was for  replies for the time this one was Locked. :D

    This topic is important to you and many others like me :).





    Tuesday, September 6, 2011 10:58 AM
  • User-776338287 posted

    Might be a late reply to this topic, but I would surely like to clear some doubts here.

     HTTPS = HTTP + SSL.

    when you access a site over SSL, there is a handshake that happens between the client and the server in order to establish the secure channel.

    This is when the client browser checks the Server certificate, and verifies its integrity. If there are any problems with the certificate, it would throw a warning message saying the same. However, its left to the end user whether he wants to proceed with this.

    Now, here comes the important part, SSL works with certificates, which solely works on the basis of TRUST between 2 communicating entities. So if the end user choses to continue despite the warning message, he is the one who is trusting the certificate by clicking on continue.

    Now, to answer the questions, is the session encrypted, YES. The session is still encrypted. But I would like to review a couple of things here.

    • Is it safe for me to continue browsing when the browser throws me a warning message?
    • Could I continue to ignore this message?

    With Self Signed certs you would see this problem more, as they are trusted only on the machine where they were created. The users could probably continue to browse if they know what they are doing. For e.g. Development environment

    However, if this were a banking website, would you make the decision to continue if a warning message were thrown. Well I personally wouldn't do so.

    To conclude, https session are always encrypted. the only way to decrypt them is to get access to the private key, which is present only on the server. If the private key is disclosed to someone else, then it is threat.

    As I said SSL is all about trust, if u decide to trust and proceed then you should also understand the implications of the same.

    Let me know if you still have any questions. I would be glad to answer them. :)

    Thursday, September 15, 2011 12:32 AM
  • User-2080516833 posted

    Thanks kaushilz.

    Regarding the role and integrity of the certificate: it would be useful to have a measure of the risk an expired certificate exposes. For example, if a valid certificate expires today: what are the security risks for today; for next week; next month etc. Presumably the risk increases over time. But, what is the likelihood: what procedure must a malicious person follow in order to take advantage of the situation, and what inconvenience or cost must they bear; does it require special equipment and so forth?

    Further, the security a certificate provides appears relative to its type and price; for example see: http://www.bestsslcertificates.com/articles8.html and http://www.globalsign.com/ssl-information-center/what-are-the-types-of-ssl-certificate.html;.

    But this thread is really a question on whether or not SSL encryption is applied when a certificate expires. The presence of ‘https:’ in the browser address bar coupled with the appearance of a “lock” symbol is enough to convince most people their connection is encrypted, regardless of the state of the certificate. The opposing view – in other words, the browser is lying - is difficult to counter technically without in depth knowledge of the SSL protocol.

    “The session is encrypted, YES” begs the question: Where is the supporting factual explanation to justify this statement. Moreover, can it be expressed in terms that people at Management level can understand?

    Saturday, September 24, 2011 11:59 AM
  • User-776338287 posted

    first of all, I am sorry for replying so late. I don't visit the forums very often.

    It doesn't matter, whether the certificate is expired. The session remains encrypted.

    However, if you insist on checking that, then you could capture a network trace for a http and https traffic. You will see the difference yourself.

    This should be able to make the management understand too. :)

    Sunday, October 23, 2011 3:18 PM
  • User1073881637 posted

    This thread isn't dead yet. :)   Capture a network trace showing plain HTTP session and encrypted HTTPS session, then print out for management.  IT"s job is to provide the information in a manner end users can understand (even when it's cryptic :)).

    Sunday, October 23, 2011 3:23 PM
  • User-2080516833 posted

    Thanks Kaushilz and Steve; and apologies for not responding sooner.

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>As mentioned earlier: a factual explanation, preferably with reference to the protocol standard, may give a stronger assuring argument over empirical evidence (which for operational reasons may be difficult to collect).

    From what I have read, SSL derives from TLS for which a neat explanation of the negotiation steps is given here: http://en.wikipedia.org/wiki/Transport_Layer_Security.

    <o:p></o:p>What this says is a connection is established in two stages:<o:p></o:p>
    1. A “handshake” during which the client and server agree the connection’s security, which involves the certificate - “The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding”<o:p></o:p>
    2. Only once the “handshake” is concluded does the connection begin, which is encrypted and decrypted until the connection closes<o:p></o:p>

    This clearly suggests encryption is applied in all circumstances provided Stage 2 is reached. In other words, by the above definition: a working connection is always encrypted; even when it follows overriding action by the user forcing the client to accept the certificate.

    Monday, November 21, 2011 1:56 PM
  • User-776338287 posted

    A slight correction, TLS is a derivative of SSL and not vice-versa.

    Regarding the SSL Handshake, I drew out a pictorial representation for one of my blogs:

    Here is the link to the blog: http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

    Link to the picture: http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-38-03-metablogapi/3835.image_5F00_622AE3A7.png

     As you understand, during SSL Handshake the client and the server decide on the protocol version, the cipher suite and then the session key that would be used for encrypting the data.

    Tuesday, November 22, 2011 12:57 PM
  • User-1672167363 posted


    The "Taming the Beast Bowser Exploit against SSL TLS" looks good.

    The IIS General Forum http://forums.iis.net/1041.aspx could use the post.




    Tuesday, November 22, 2011 1:08 PM
  • User-2064283741 posted

     If you are worried about BEAST

    see if you are vulnerable here:


    (like iis.net appear to be :) https://www.ssllabs.com/ssldb/analyze.html?d=iis.net) 

    From what I understand the workaround of ordering ciphers is not 100% generated as there is no know fix for this. I is just recommended as a slow down of the attack.

    And you this brilliant free tool to easily reorder ciphers and one click PCI complacency, etc


    Tuesday, November 22, 2011 5:24 PM
  • User-776338287 posted

    Nah! He wasn't concerned about the BEAST. It was just regarding HTTPS.

    as far as the vulnerability related to SSL is concerned, it is only sen with CBC based ciphers. so if you disable them it would be considered a fix. or move to TLS 1.1/TLS 1.2, which again is something you want to consider.

    Tuesday, November 22, 2011 5:51 PM
  • User-2064283741 posted


    Nah! He wasn't concerned about the BEAST.



    I was referring to Hcamper who voiced interest or maybe the microsoft IIS.net admin. ;)


    . or move to TLS 1.1/TLS 1.2, which again is something you want to consider.


    Enabling only TLS1.1+ is not really practical for most.

    Most clients will not support it. You have to configure all Microsoft OSs and IE to enable these.

    Even Windows 7 and IE 9 by default does not support TLS 1.1+ only SSL 3.0 and TLS 1.0 you have to go into the setting to enable.

    For admin I would not recommend switching to to TLS 1.1+ only. That is crazy.

    We are 5+ years away dropping SSL3 let alone TLS1.0 support until Windwos 7 goes EOL or maybe a little less if a Service Pack enforces IE10/enables TLS 1.1+ in IE9

    Tuesday, November 22, 2011 6:34 PM
  • User-2064283741 posted

    Nah! He wasn't concerned about the BEAST. It was just regarding HTTPS.

    as far as the vulnerability related to SSL is concerned, it is only sen with CBC based ciphers. so if you disable them it would be considered a fix. or move to TLS 1.1/TLS 1.2, which again is something you want to consider.


    Also I wanted to add that AFAIK the if you remove all CBC you are left with RC4 which is only up 128bits. Which are fairly weak.

    And this non-compliant to some standards like FIPS 140-2


    That is what I meant by no real solution to the BEAST attack.

    This is not just an IIS problem, all web servers have the same issues it is a weakness in TLS1.0


    Tuesday, November 22, 2011 6:58 PM
  • User-1672167363 posted


    Yes "HCamper" Martin is interested and learning. :D.

    The current Readers ( 50,312 ) are also interested.




    Tuesday, November 22, 2011 10:01 PM
  • User-776338287 posted

    you are right. the RC4 ciphers are compartively weaker against CBC based ciphers. I am not sure about the FIPS complaint part, as most of the online servers prefer RC4 ciphers after the BEAST vulnerability was disclosed. :)

    The problem is all because of the use of implicit IV's or Initialisation vectors. You can refer to my blog link I posted in my previous response for BEAST. In this the output of the previous block is used as input for the current block to perform operations, which creates a relationship between the current and the previous block, thus making it vulnerable to crack down.

    This problem is addressed in TLS 1.1 by replacing Implicit IV's with explicit IVs. Now we have separate IV's for each blocks.

    here is a snippet from RFC4346:

    Differences from TLS 1.0

       This document is a revision of the TLS 1.0 [TLS1.0] protocol, and
       contains some small security improvements, clarifications, and
       editorial improvements.  The major changes are:

       -  The implicit Initialization Vector (IV) is replaced with an
          explicit IV to protect against CBC attacks [CBCATT].

       -  Handling of padding errors is changed to use the bad_record_mac
          alert rather than the decryption_failed alert to protect against
          CBC attacks.

    I wonder if the same could be applied to TLS 1.0. and I think its time for the Internet security standards to completely embrace TLS 1.1 and TLS 1.2. Its better to use a solution which is already there rather than sitting and fixing the BUGS in current standards.

    Well, we can always sit and debate about this, as long as this is a healthy one, I would be active. :)

    Wednesday, November 23, 2011 11:33 AM
  • User-2064283741 posted

    I hope I am being healthy in this debate.

    I agree that the TLS 1.1+ is better and should be embraced everywhere. TLS1.0 and before are broken and insecure.

    But I still don't see how this can be obtained in the real world.

    To be secure you will need clients only using TLS 1.1+ and servers only using TLS1.1+

    All versions of clients browser running Windows IE don't support it by default. It is there but unchecked by default.

    If the clients browsers do not use/support it then why will make your webserver exclusively support it.
    I am not just picking on IE here. In fact it seems the best browser for SSL security.  
    From what I understand Firefox still does not even have the option have TLS 1.1 support or above.


    And I don't think Chrome does either.

    So in conclusion no (mainstream) browser out there supports TLS 1.1 or above.  

    The bigger issue for wide adoption of this is the client browser not the server technologies.

    Making it secure by turning off TLS 1.0 is a bit like securing a server by unplugging it. ;)

    Other thoughts on workaround solutions with a record splitting option which sounds like one of the ideas you are proposing.

    Wednesday, November 23, 2011 1:15 PM
  • User-776338287 posted

    yea, adoption is a problem here. Both from Server and Clients perspective. Among clients, IE 8/9 (running on win7/win 2008 r2) and Opera are the 2 browsers which support TLS 1.1 and TLS 1.2. Among servers its only Windows Server 2008 R2, so it would mean IIS 7.5 is the only web server out there which supports these.

    The latest version of Firefox i.e., V 8.0, chrome or Safari don't support them. I don't understand how could they claim themselves to be the most secure when they don't support the latest security protocols. That too they have been out there for more than 5 years. :) Yea, I am kinda picking on the non-MS browsers. ;)

    As far as TLS support for IE is considered. IE is actually dependent on the TLS support of the underlying OS for that. By default they are disabled, and we will have to enable it via registry. I don't know why they have disabled by default. I would prefer to have them enabled. :)

    Infact any MS product relies on the uderlying OS component (Schannel) for TLS support.

    The same applies for IIS 7.5. Now considering Apache, it relies on OPENSSL for TLS support. OPENSSL doesn't support TLS 1.1 & further. Its a wide problem that we have here. adoption of standards is not being done apporpriately.

     As far as BEAST is considered, the attacker needs to be on the same network to perform the attack and should have been listening to the conversation from the beginning. eavesdropping during the conversation will  not help at all.

    Wednesday, November 23, 2011 1:47 PM
  • User-2064283741 posted

    yea, adoption is a problem here. Both from Server and Clients perspective. Among clients, IE 8/9 (running on win7/win 2008 r2) and Opera are the 2 browsers which support TLS 1.1 and TLS 1.2. Among servers its only Windows Server 2008 R2, so it would mean IIS 7.5 is the only web server out there which supports these.


    I was under the impression that you can configuration 2003 and upwards (maybe NT4 onwards...) to use TLS 1.1+ only.

    I thought it was all in SCHANNEL reg settings on the machine.

    If you remove them there under the SCHANNEL\Protocols SubKey can you not configure it to have only TLS 1.1+ are installed on the machine. That way the serverw ill not have access to them and it will be secure.

    under the SCHANNEL reg is where you remove weak ciphers from the machine and they cannot be accessed making you safe.

    This article talks about NT4 onwards doing SCHANNEL\Protocols\TLS 1.1+ reg settings



    • SCHANNEL\Protocols\TLS 1.1\Client
    • SCHANNEL\Protocols\TLS 1.1\Server
    • SCHANNEL\Protocols\TLS 1.2\Client
    • SCHANNEL\Protocols\TLS 1.2\Server"



    So that implies you can do it from that NT4 onwards.

    Am I mistaken with my analysis?

    NB that tool https://www.nartac.com/Products/IISCrypto/Default.aspx does all the SCHANNEL reg stuff for you.


    Wednesday, November 23, 2011 2:26 PM
  • User-776338287 posted

    you cannot enable TLS 1.1 or 1.2 for Windows Server 2003 or even Windows Server 2008. Adding a registry won't help as the underlying OS doesn't support it.

    The support article needs to be corrected.

    The support for TLS is at the OS layer. As I mentioned earlier Win 7 and Win 2008 R2 are the only 2 OS which support this. I have blogged it here: http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

    you could verify this via a simple check. Run IE 8 on XP, vista & win 7. IE 9 runs on visa and win 7 only.

    In IE go to Tools-> Internet Options->Advanced Tab->Security section (scroll to the bottom)

    You would see only 3 protocols listed for XP and Vista. However. 5 protocols would be displayed for Win 7. :)

    Wednesday, November 23, 2011 6:44 PM
  • User-2064283741 posted

    Thanks for the explanation. I understand now. It wasn't very clear there. I didn't really think really old version of WIndwos could do TLS 1.1+ (it wasn''t even released) but I thought 2003 could. There are a lot of settings in the CrypoAPI schannel thing and not all of them documented well. Thus I concluded that the support was at the OS layer but only new version of IE that had the registry hooks into SCHANNEL.

    Looking into it more see that it is only the very latest version of Windows has TLS 1.1 or above.


    Wednesday, November 23, 2011 7:39 PM
  • User979669096 posted

    Hi All,

    I agree with kaushilz, on the TLS support for windows OS. Adding registry keys would not make any difference on unsupported OS's. The schannel (C:\Windows\System32\schannel.dll) will not honor it as it does not support it.

     - Ziz

    Wednesday, November 23, 2011 11:43 PM
  • User-776338287 posted

    I agree we need to have better documentation around this. Anyways I blogged this as well.

    Here is the link: http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

    I hope this should be suffice. I am open to feedback. :)

    Thursday, November 24, 2011 3:20 PM