[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Server Name Indication?
I also found some forum posts that seemed to indicate to send it first and resend if errors. There were several discussions about what to do if it fails. I liked "let it fail with a message indicating server misconfiguration". ;-) Probably not the best way to get work accomplished though.
There might need to be a directive or run-time parameter to not include that code at earlier gskit levels. Not sure how to implement that.
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of thomas.raddatz@xxxxxx
Sent: Wednesday, January 15, 2014 2:01 AM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: 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:
https://bugzilla.mozilla.org/show_bug.cgi?id=116168
The following blog entry anounces SNI for IE7 back in 2005:
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:
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 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 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
> >
> >
> > 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:
> > > 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
> >
-----------------------------------------------------------------------
> >
>
>
>
> --
> ------------------------------------------------------
> Ted Holt
> Senior Technical Editor, Four Hundred Guru
> ==============================================
> Sign up for free IT-related newsletters at www.itjungle.com!
> ==============================================
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> 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.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------