Bug report regarding SSL library used by Sharepoint web server

Question

I have attempted to report this by email to the [email protected] address, but they tell me this is not the correct address to use and have refused to give me a better one or forward my bug report on to the correct people. I'm hoping that by posting it here I will get the attention of someone who can fix the problem.PROBLEM DESCRIPTION:Accessing the Sharepoint web servers (157.55.229.87) is not possible from a Scientific Linux 6.5 system using OpenSSL 1.0.1e. Analysis of the network traffic shows the client successfully connects to the server and sends a TLS handshake. The server responds with a TCP ACK, but does not include a TLS handshake response. After 30 seconds the server tears the connection down with a TCP RST.
This is reproducable with the following command:
openssl s_client -showcerts -connect sexeysschool-my.sharepoint.com:443
DIAGNOSIS:
The client's TLS handshake contains several length fields - one in the TLSv1 record layer, another in the Client Hello handshake payload and one for each of the cipher suites list and extension list. Each of the length headers is 16 bits long, so should be able to contain any value up to 65535.
By hand-editing the handshake packet and replaying it, I have discovered that if the value of the TLSv1 record layer length header is <= 255, the Sharepoint server responds correctly. However, if the length header exceeds 255, the Sharepoint server does not respond.
Under Scientific Linux 6.5, 74 cipher suites (totalling 148 octets) and 5 extensions (totalling 65 octets) are presented by the client, yielding a TLSv1 record layer length of 258 octets.
Please let me know if I can be of any further help, and if possible it would be useful to have some feedback regarding this issue so that we can keep our customers informed.

Answer 1

Hi Mark,
According to your description, my understanding is that the Article Date column displayed with the value based on GMT0 in the Refinement web part.
Microsoft SharePoint stores date and time values in Coordinated Universal Time (UTC, but also named GMT or Zulu) format, and almost all date and time values that are returned by members of the object model are in UTC format. So the value
of the Article Date column stores the date and time in UTC format in the database, and the search indexes the UTC value of the Article Date column after crawling the database so that it displays the UTC value in Refinement web part.
The list column values displayed in the lists that are obtained through the indexer for the SPListItem class are already formatted in the local time for the site so if you’re working on current context list item and fetch a datetime field
like so SPContext.Current.ListItem["Your-DateTime-Field"] you’ll retrieve a DateTime object according the specified time zone in the regional settings.
More references:
http://francoisverbeeck.wordpress.com/2012/05/24/sharepoint-tip-of-the-day-be-careful-when-wor/
Thanks,
Victoria
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Victoria Xia
TechNet Community Support