[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Server Name Indication?



   Ted,
   I found a discussion about SNI at "Bugzilla@Mozilla" where "Server name
   indicatoin" was first mentioned in 2002. So it seems to be older that
   expected:
   [1]https://bugzilla.mozilla.org/show_bug.cgi?id=116168
   The following blog entry anounces SNI for IE7 back in 2005:
   [2]http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
   Next I found RFC 3546, which describes how to add extensions to the
   client "Hello" message:
   [3]http://www.ietf.org/rfc/rfc3546.txt
   Last but not least here is a Wireshark trace of Firefox 20 connecting
   to "email.1und1.de". As you can see, Firefox immediately sends the
   server name extension, because it can safely assume that current
   servers properly ignore unsupported (unkown) "Hello" extensions:
   HTTP     260    CONNECT email.1und1.de:443 HTTP/1.1
   HTTP     260    GET [4]http://http.xxx.xxx.xxx.xxx/xxx/ HTTP/1.1
   HTTP     216    HTTP/1.1 200 OK
   HTTP     105    HTTP/1.1 200 Connection established
   TLSv1    237    Client Hello
   Secure Sockets Layer
       TLSv1 Record Layer: Handshake Protocol: Client Hello
           Content Type: Handshake (22)
           Version: TLS 1.0 (0x0301)
           Length: 166
           Handshake Protocol: Client Hello
               Handshake Type: Client Hello (1)
               Length: 162
               Version: TLS 1.0 (0x0301)
               Random
               Session ID Length: 0
               Cipher Suites Length: 72
               Cipher Suites (36 suites)
               Compression Methods Length: 1
               Compression Methods (1 method)
               Extensions Length: 49
               Extension: server_name
                   Type: server_name (0x0000)
                   Length: 19
                   Server Name Indication extension
               Extension: elliptic_curves
               Extension: ec_point_formats
               Extension: SessionTicket TLS
               Extension: next_protocol_negotiation
   TLSv1    1414   Server Hello
   TLSv1    716    Certificate
   TLSv1    264    Client Key Exchange, Change Cipher Spec,
                   Encrypted Handshake Message
   TLSv1    348    New Session Ticket, Change Cipher Spec,
                   Encrypted Handshake Message
   OCSP     567    Request
   HTTP     260    GET [5]http://http.xxx.xxx.xxx.xxx/xxx/ HTTP/1.1
   HTTP     215    HTTP/1.1 200 OK
   OCSP     476    Response
   TLSv1    1676   Application Data, Application Data
   TLSv1    1414   Application Data, Application Data
   TLSv1    290    Application Data
   TLSv1    1724   Application Data, Application Data
   TLSv1    1414   Application Data, Application Data
   TLSv1    450    Application Data
   TLSv1    1820   Application Data, Application Data
   TLSv1    1060   Application Data, Application Data, Application Data,
                   Application Data, Application Data, Application Data,
                   Application Data, Application Data, Application Data,
                   Application Data
   I assume that Firefox resends the request without the SNI extension in
   case it gets back an error from the server as mentioned in the MSDN
   blog:
   "Unfortunately, anecdotal data indicates that some TLS servers in the
   wild are not RFC-compliant and immediately fail the connection when TLS
   extensions are present."
   Thomas.
   ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 14.01.2014 17:43:45:
   > Von: fourhundredguru@xxxxxxxxx
   > An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx,
   > Datum: 14.01.2014 19:04
   > Betreff: Re: Server Name Indication?
   > Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   >
   > I have learned a good bit about Server Name Indication (SNI), but not
   as
   > much as I need to know.
   >
   >
   > To make HTTPAPI work with SNI, I patched procedure https_init in
   module
   > COMMSSLR4.   I hard-coded a call to gsk_attribute_set_buffer.
   >
   >
   > eval      rc = gsk_attribute_set_buffer(
   >
   >            wkEnvh: 231:
   >
   >            ServerName: 19)
   >
   > if        rc <> GSK_OK
   >
   > callp     SetError(HTTP_GSKKEYF:
   >
   >             'SNI error: ' +
   >
   >             ssl_error(rc))
   >
   > callp     https_cleanup
   >
   > return    -1
   >
   > endif
   >
   >
   >
   > I used the value 231 in the second parm.  Constant
   > GSK_SSL_EXTN_SERVERNAME_CRITICAL_REQUEST would need to be defined in
   > GSKSSL_H.
   >
   >
   > It is possible that 230 would also work.  If so, then constant
   > GSK_SSL_EXTN_SERVERNAME_REQUEST would also need to be added to
   GSKSSL_H.
   >
   >
   > There was an error in one of IBM's programs that prevented me from
   > connecting successfully to the web service.  IBM fixed the program
   with PTF
   > MF57749.  TR7 is prerequisite.
   >
   >
   > As I understand it, SNI is relatively new and growing.  People like
   the
   > idea of getting by with fewer IP addresses.  If so, the need to
   support SNI
   > isn't going to go away.  I don't know what the permanent solution is.
   > Maybe https_init needs an optional fifth parameter for the host name.
    If
   > this parm is not blank, then https_init calls
   gsk_attribute_set_buffer.
   > But then I wonder if it should use 230 or 231.
   >
   >
   > I am told that modern browsers support SNI, but I can't find any
   > information on how they do so.  Do they automatically send the
   attribute
   > for SNI?  Do they try to connect without SNI, and if that doesn't
   work,
   > retry with the SNI attribute?  I'd love to know. It seems to me that
   > whatever they do, HTTPAPI needs to do the same.
   >
   >
   > On Fri, Dec 13, 2013 at 5:52 PM, Mike Krebs
   <mkrebs@xxxxxxxxxxxxxxxxxx>wrote:
   >
   > > At least in 7.1, it appears to be in GSKIT
   > >
   > >
   > >
   [6]http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
   > 2Fapis%2Fgsk_attribute_set_buffer.htm
   > >
   > > GSK_SSL_EXTN_SERVERNAME_REQUEST (230)
   > > GSK_SSL_EXTN_SERVERNAME_CRITICAL_REQUEST (231)
   > > GSK_SSL_EXTN_SERVERNAME_LIST (232)
   > > GSK_SSL_EXTN_SERVERNAME_CRITICAL_LIST (233)
   > >
   > >
   > >
   > >
   > > -----Original Message-----
   > > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:
   > > ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
   > > Sent: Friday, December 13, 2013 3:18 PM
   > > To: HTTPAPI and FTPAPI Projects
   > > Subject: Re: Server Name Indication?
   > >
   > > Hi Ted,
   > >
   > > HTTPAPI does not have it's own code for SSL.   It merely calls the
   GSKit
   > > APIs for SSL that IBM provides with the operating system.
   > >
   > > Server Name Indication (SNI) is a feature of SSL, not a feature of
   HTTP,
   > > so there's no way I can implement this.  IBM would have to do it.
   > >
   > > -SK
   > >
   > >
   > >
   > > On 12/13/2013 9:23 AM, ted_holt@xxxxxxxxxxxxxxxx wrote:
   > > >     Does HTTPAPI support Server Name Indication?   I am having
   trouble
   > > >     communicating with a Web service, and this is what they have
   found
   > > out
   > > >     from our trouble-shooting.
   > > >     The issue is something called ?SNI? or ?Server Name
   Indication?. We
   > > >     have several API websites running off the same IP, each with
   its own
   > > >     certificate. SNI forces the client to tell them what host
   they are
   > > >     looking for so it knows which certificate to dish up. SNI is
   built in
   > > >     to all modern day browsers and that?s why we don?t have any
   problems
   > > >     from RestClient or any other testing facilities. If im
   correct, I
   > > don?t
   > > >     think the utility you are using is implementing SNI and when
   it
   > > >     contacts our server the server doesn?t know what its looking
   for.
   > > >
   > > >     You were able to make a call to the api through SSL during
   out test
   > > >     yesterday because I disabled SNI, and just set one
   certificate for
   > > the
   > > >     IP, but that renders all the other sites dead. SNI is a
   fairly common
   > > >     thing, so the software you are using should have the ability
   to
   > > >     implement it somewhere in there.
   > > >     Ted Holt
   > > >     Sr. Systems Analyst
   > > >     The Taylor Group of Companies
   > > >     650 N. Church Avenue
   > > >     Louisville, MS 39339
   > > >     Phone: (662) 773-9186
   > > >     NOTICE:
   > > >     This message (with any attachments) is confidential and may
   > > constitute
   > > >     a privileged communication. If you have received this message
   in
   > > error,
   > > >     please notify me immediately by telephone (662-773-3421) or
   by
   > > >     electronic mail. Do not use or disclose this message in any
   way.
   > > >     Thank you
   > > >
   > > >
   > > >
   > > >
   -----------------------------------------------------------------------
   > > > This is the FTPAPI mailing list.  To unsubscribe, please go to:
   > > > [7]http://www.scottklement.com/mailman/listinfo/ftpapi
   > > >
   -----------------------------------------------------------------------
   > >
   > >
   -----------------------------------------------------------------------
   > > This is the FTPAPI mailing list.  To unsubscribe, please go to:
   > > [8]http://www.scottklement.com/mailman/listinfo/ftpapi
   > >
   -----------------------------------------------------------------------
   > >
   >
   >
   >
   > --
   > ------------------------------------------------------
   > Ted Holt
   > Senior Technical Editor, Four Hundred Guru
   > ==============================================
   > Sign up for free IT-related newsletters at [9]www.itjungle.com!
   > ==============================================
   >
   -----------------------------------------------------------------------
   > This is the FTPAPI mailing list.  To unsubscribe, please go to:
   > [10]http://www.scottklement.com/mailman/listinfo/ftpapi
   >
   -----------------------------------------------------------------------

   --
   IMPORTANT NOTICE:
   This email is confidential, may be legally privileged, and is for the
   intended recipient only. Access, disclosure, copying, distribution, or
   reliance on any of it by anyone else is prohibited and may be a
   criminal
   offence. Please delete if obtained in error and email confirmation to
   the sender.

References

   1. https://bugzilla.mozilla.org/show_bug.cgi?id=116168
   2. http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
   3. http://www.ietf.org/rfc/rfc3546.txt
   4. http://http.xxx.xxx.xxx.xxx/xxx/
   5. http://http.xxx.xxx.xxx.xxx/xxx/
   6. http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
   7. http://www.scottklement.com/mailman/listinfo/ftpapi
   8. http://www.scottklement.com/mailman/listinfo/ftpapi
   9. file://localhost/tmp/www.itjungle.com!
  10. http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------