/dev/null
- Overig
support.microsoft.com bugje?
24-09-2014, 17:04 door Erik van Straten, 20 reacties
Nauwelijks een security probleem, daarom in /dev/null (aan de andere kant, beschikbaarheid valt ook onder ISO 27001 ;)
Vandaag heb ik al een paar keer gezien dat "support.microsoft.com" URLs de bekende bovenkant en onderkant van MS support pagina's oplevert, maar als content voor bijvoorbeeld http://support.microsoft.com/kb/2977629 (laatste MSIE patch) slechts:
Oops!
The page you are looking for may have a new location, or is no longer available.
Het reproduceert niet, als ik de browser refresh verschijnt de verwachte inhoud wel, en als ik het wat later nog een keer probeer gaat het meestal in 1x goed. Het probleem komt dus echt maar sporadisch voor.
Ik zag het vanochtend ook bij http://support.microsoft.com/kb/2998527 (d.w.z. de gisteren verschenen Russische timezone patch, zie: https://www.security.nl/posting/403094/1-2+MS+patches+released+vandaag). Het probleem is dus niet specifiek voor 1 URL.
Googlen naar: "Oops!" "The page you are looking for may have a new location, or is no longer available"
lijkt erop te wijzen dat dit probleem al wel eens lang zou kunnen bestaan; op verschillende forums zie je mensen de "oops" melden m.b.t. diverse KB nummers en vervolgens anderen antwoorden dat het bij hen probleemloos werkt.
Verwarrend is dat deze melding kennelijk ook reproduceerbaar optreedt als Microsoft een patch (tijdelijk) terugtrekt, maar bij de 2 URL's die ik bovenaan noem is daar -bij mijn weten- geen sprake van.
Deze bijdrage in elk geval om te waarschuwen: mocht je zo'n "Oops!" zien, dan wil dat niet zeggen dat de pagina niet bestaat, maar daarnaast ik ben benieuwd of anderen dit ook hebben gemerkt of nog steeds zien gebeuren.
Vandaag heb ik al een paar keer gezien dat "support.microsoft.com" URLs de bekende bovenkant en onderkant van MS support pagina's oplevert, maar als content voor bijvoorbeeld http://support.microsoft.com/kb/2977629 (laatste MSIE patch) slechts:
Oops!
The page you are looking for may have a new location, or is no longer available.
Het reproduceert niet, als ik de browser refresh verschijnt de verwachte inhoud wel, en als ik het wat later nog een keer probeer gaat het meestal in 1x goed. Het probleem komt dus echt maar sporadisch voor.
Ik zag het vanochtend ook bij http://support.microsoft.com/kb/2998527 (d.w.z. de gisteren verschenen Russische timezone patch, zie: https://www.security.nl/posting/403094/1-2+MS+patches+released+vandaag). Het probleem is dus niet specifiek voor 1 URL.
Googlen naar: "Oops!" "The page you are looking for may have a new location, or is no longer available"
lijkt erop te wijzen dat dit probleem al wel eens lang zou kunnen bestaan; op verschillende forums zie je mensen de "oops" melden m.b.t. diverse KB nummers en vervolgens anderen antwoorden dat het bij hen probleemloos werkt.
Verwarrend is dat deze melding kennelijk ook reproduceerbaar optreedt als Microsoft een patch (tijdelijk) terugtrekt, maar bij de 2 URL's die ik bovenaan noem is daar -bij mijn weten- geen sprake van.
Deze bijdrage in elk geval om te waarschuwen: mocht je zo'n "Oops!" zien, dan wil dat niet zeggen dat de pagina niet bestaat, maar daarnaast ik ben benieuwd of anderen dit ook hebben gemerkt of nog steeds zien gebeuren.
Reacties (20)
Door Erik van Straten:
[...] daarnaast ik ben benieuwd of anderen dit ook hebben gemerkt of nog steeds zien gebeuren.
[...] daarnaast ik ben benieuwd of anderen dit ook hebben gemerkt of nog steeds zien gebeuren.
Ik had het eerder nog niet gezien,
maar bij het zonet uitproberen met de twee support.microsoft.com URL's die je hierboven noemde,
trad het op met de eerste URL. Er was zelfs 2x refresh (F5) nodig om de pagina correct te tonen.
Bij het een paar minuten later nog eens proberen, leverden beide URL's dat "Oops!" fenomeen.
Diverse malen refresh hielp nu zelfs niet eens.
Pas na even wachten en daarna nog eens proberen liet refresh vervolgens de pagina correct verschijnen.
Server- of verbindings-problemen bij Microsoft Support?
Heb net ook even gekeken...
De grap is dat ik het met Chrome en FF niet voor elkaar kreeg, maar het alleen met IE heb kunnen reproduceren :p
Zegt niets natuurlijk, maar vind het toch wel frappant.
De grap is dat ik het met Chrome en FF niet voor elkaar kreeg, maar het alleen met IE heb kunnen reproduceren :p
Zegt niets natuurlijk, maar vind het toch wel frappant.
Als het probleem zich soms wel en soms niet voordoet doet mij denken aan een issue met 1 server achter een loadbalancer. De rest van de servers achter de loadbalancer doen het wel goed, maar die ene niet. Het is dus maar een gokje of je juist op die ene uitkomt of niet.
Het fenomeen van het probleem houden bij snel refreshen en niet het probleem hebben bij langzaam refreshen duidt in mijn ogen ook nog altijd op een loadbalancer. Waarschijnlijk laat die loadbalancer je bij veel requests snel achter elkaar op dezelfde server uitkomen. Pas na het verstrijken van de stickiness-tijd kom je weer uit op een willekeurige server.
Het fenomeen van het probleem houden bij snel refreshen en niet het probleem hebben bij langzaam refreshen duidt in mijn ogen ook nog altijd op een loadbalancer. Waarschijnlijk laat die loadbalancer je bij veel requests snel achter elkaar op dezelfde server uitkomen. Pas na het verstrijken van de stickiness-tijd kom je weer uit op een willekeurige server.
Het reproduceert niet, als ik de browser refresh verschijnt de verwachte inhoud wel, en als ik het wat later nog een keer probeer gaat het meestal in 1x goed. Het probleem komt dus echt maar sporadisch voor.
Zelfde 'probleem' hier na F5 ging hij na een tijdje wel.
24-09-2014, 20:53 door
Erik van Straten
Dank voor de snelle bevestigingen en loadbalancer suggestie!
Bij mij trad het juist op in Firefox, met MSIE kreeg ik het niet gereproduceerd.
Zojuist getest, in MSIE: https://support.microsoft.com/kb/2977629 (de laatste MSIE update): geen probleem
In Firefox: https://support.microsoft.com/kb/2998527 (tijdzones .ru): meteen een Oops!
Ik ga vanavond nog wat verder testen met zowel de https als http varianten van de URL's, kennelijk treedt het probleem met beide protocollen op. Dit sluit aan op de loadbalancer suggestie, hier zal een loadbalancer wel de SSL termination op zich nemen.
Daarnaast uitzoeken of ik kan vinden waar de betreffende servers staan, want Microsoft distribueert deze content via Akamai. En vervolgens ook uitzoeken waar ik dit probleem het beste kan melden. Als iemand toevallig informatie heeft over deze laatste 2 punten, dan is dat natuurlijk welkom!
Bij mij trad het juist op in Firefox, met MSIE kreeg ik het niet gereproduceerd.
Zojuist getest, in MSIE: https://support.microsoft.com/kb/2977629 (de laatste MSIE update): geen probleem
In Firefox: https://support.microsoft.com/kb/2998527 (tijdzones .ru): meteen een Oops!
Ik ga vanavond nog wat verder testen met zowel de https als http varianten van de URL's, kennelijk treedt het probleem met beide protocollen op. Dit sluit aan op de loadbalancer suggestie, hier zal een loadbalancer wel de SSL termination op zich nemen.
Daarnaast uitzoeken of ik kan vinden waar de betreffende servers staan, want Microsoft distribueert deze content via Akamai. En vervolgens ook uitzoeken waar ik dit probleem het beste kan melden. Als iemand toevallig informatie heeft over deze laatste 2 punten, dan is dat natuurlijk welkom!
Het wisselt bij mij wat ik te zien krijg
Ik kreeg het volgende te zien: Oops!/ de pagina te zien/ Een lege pagina/ de melding dat de webpagina niet kon worden weergeven.
update 24-09-2014 22:16
Bij het bezoeken van https://support.microsoft.com/kb/2977629 kreeg ik meteen Oops! te zien.
Een lege pagina of de melding dat de webpagina niet kan worden weergeven heb ik niet meer gekregen.
update 24-09-2014 22:52
Bij mij trad het op in zowel IE als in Firefox.
Ik kreeg het volgende te zien: Oops!/ de pagina te zien/ Een lege pagina/ de melding dat de webpagina niet kon worden weergeven.
update 24-09-2014 22:16
Bij het bezoeken van https://support.microsoft.com/kb/2977629 kreeg ik meteen Oops! te zien.
Een lege pagina of de melding dat de webpagina niet kan worden weergeven heb ik niet meer gekregen.
update 24-09-2014 22:52
Bij mij trad het op in zowel IE als in Firefox.
24-09-2014, 22:26 door
Eric-Jan H te D
Niet direct MS de schuld geven. Ze gebruiken voor zover ik weet Akamai als Content Deliverer.
Bij het bezoeken van http://www.microsoft.com/netherlands/msnederland/default.aspx kreeg ik overigens 3 maal een melding (502):
Server Error
Of dit overigens iets te maken heeft met het hier boven besproken weet ik niet, maar ik zet het hier toch maar even neer.
Server Error
Of dit overigens iets te maken heeft met het hier boven besproken weet ik niet, maar ik zet het hier toch maar even neer.
Ik denk dat er ergens een time-out plaatsvindt, en dat daarom de request leidt tot die "oops"-melding.
(omdat de benodigde data niet op tijd werd opgehoest door de database, denkt het systeem dat de pagina niet bestaat?)
De (te laat) vergaarde data belandt vervolgens ergens in een cache, zodat het de tweede keer goed gaat,
omdat de data dan wél (vanuit de cache) tijdig beschikbaar komt.
Een andere variant van zoiets overkwam mij trouwens de afgelopen maanden bij bezoeken van http://nl.tp-link.com
en http://www.tp-link.com/nl-be/. (deze servers schijnen in St.Petersburg (Rusland) resp. USA te staan)
Beide websites gaven nogal vaak "address not found", hetgeen duidt op een DNS probleem.
(werd bevestigd door het feit dat ik dus wél verbinding kreeg in geval ik het IP-adres van zo'n tp-link website intikte!...)
DNS-instelling van router was ingesteld op de DNS-servers van de provider. Andere websites gaven geen enkel probleem.
(op dit moment gaan die beide tp-link websites trouwens goed zie ik)
Iemand die het verschijnsel van regelmatig slecht bereikbare tplink-webservers herkent?
Mvg, cluc-cluc
(omdat de benodigde data niet op tijd werd opgehoest door de database, denkt het systeem dat de pagina niet bestaat?)
De (te laat) vergaarde data belandt vervolgens ergens in een cache, zodat het de tweede keer goed gaat,
omdat de data dan wél (vanuit de cache) tijdig beschikbaar komt.
Een andere variant van zoiets overkwam mij trouwens de afgelopen maanden bij bezoeken van http://nl.tp-link.com
en http://www.tp-link.com/nl-be/. (deze servers schijnen in St.Petersburg (Rusland) resp. USA te staan)
Beide websites gaven nogal vaak "address not found", hetgeen duidt op een DNS probleem.
(werd bevestigd door het feit dat ik dus wél verbinding kreeg in geval ik het IP-adres van zo'n tp-link website intikte!...)
DNS-instelling van router was ingesteld op de DNS-servers van de provider. Andere websites gaven geen enkel probleem.
(op dit moment gaan die beide tp-link websites trouwens goed zie ik)
Iemand die het verschijnsel van regelmatig slecht bereikbare tplink-webservers herkent?
Mvg, cluc-cluc
25-09-2014, 02:18 door
Erik van Straten
Ik heb ondertussen enkele Wireshark captures van "Oops" (en natuurlijk van gewone pagina's). Naast de content verschilt ook de wijze van verzenden, zoals blijkt uit het eerste pakketje na elke request.
Eerste ontvangen pakket van "Oops" pagina:
Eerste ontvangen pakket van verwachte pagina:
Nb. hierboven heb ik de lange Cookie regels gewrapped, anders paste het niet in de breedte (en ik heb de 2e en 3e regel met Alt-255 spaties laten inspringen voor de leesbaarheid).
Opvallend is het ontbreken van "chunked encoding", gzip en "Vary: Accept-Encoding" in de Oops pagina.
Eerste ontvangen pakket van "Oops" pagina:
HTTP/1.1 404 Not Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.0
Set-Cookie: .ASPXANONYMOUS=lIQMC98O0AEkAAAAYzhjYjdjNzgtMzhjNS00
NTIzLThkOWMtZDhlMDk2ODgyZTljjCkfdoOhS2_yDAAyNrLQ2LPuGygrU9cvq0
GL00wY4ys1; expires=Wed, 03-Dec-2014 09:53:51 GMT; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
Set-Cookie: SMC_SAGE=T1; expires=Thu, 24-Sep-2015 23:13:51 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Set-Cookie: smcexpticket=100;expires=Thu, 31-Dec-2015 23:59:59 GMT; Path=/; HttpOnly;
Set-Cookie: smcexpsessionticket=100; Path=/; HttpOnly;
Date: Wed, 24 Sep 2014 23:13:51 GMT
Content-Length: 98627
<!DOCTYPE html [...]
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.0
Set-Cookie: .ASPXANONYMOUS=lIQMC98O0AEkAAAAYzhjYjdjNzgtMzhjNS00
NTIzLThkOWMtZDhlMDk2ODgyZTljjCkfdoOhS2_yDAAyNrLQ2LPuGygrU9cvq0
GL00wY4ys1; expires=Wed, 03-Dec-2014 09:53:51 GMT; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
Set-Cookie: SMC_SAGE=T1; expires=Thu, 24-Sep-2015 23:13:51 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Set-Cookie: smcexpticket=100;expires=Thu, 31-Dec-2015 23:59:59 GMT; Path=/; HttpOnly;
Set-Cookie: smcexpsessionticket=100; Path=/; HttpOnly;
Date: Wed, 24 Sep 2014 23:13:51 GMT
Content-Length: 98627
<!DOCTYPE html [...]
Eerste ontvangen pakket van verwachte pagina:
HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
Set-Cookie: .ASPXANONYMOUS=dK1FON8O0AEkAAAAMTEwZDVmMWQtMDdkNS0
0NTJiLWI0MmMtYjM3NTMzZTEyNWYwQtwL5gHo0-Nsxftqz2YcqtaLw01FNmUO
SxqotLa-Lxo1; expires=Wed, 03-Dec-2014 09:55:07 GMT; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
Set-Cookie: SMC_SAGE=T1; expires=Thu, 24-Sep-2015 23:15:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Set-Cookie: smcexpticket=100;expires=Thu, 31-Dec-2015 23:59:59 GMT; Path=/; HttpOnly;
Set-Cookie: smcexpsessionticket=100; Path=/; HttpOnly;
Date: Wed, 24 Sep 2014 23:15:08 GMT
10986
<gzipped bytes>
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
Set-Cookie: .ASPXANONYMOUS=dK1FON8O0AEkAAAAMTEwZDVmMWQtMDdkNS0
0NTJiLWI0MmMtYjM3NTMzZTEyNWYwQtwL5gHo0-Nsxftqz2YcqtaLw01FNmUO
SxqotLa-Lxo1; expires=Wed, 03-Dec-2014 09:55:07 GMT; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
Set-Cookie: SMC_SAGE=T1; expires=Thu, 24-Sep-2015 23:15:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Set-Cookie: smcexpticket=100;expires=Thu, 31-Dec-2015 23:59:59 GMT; Path=/; HttpOnly;
Set-Cookie: smcexpsessionticket=100; Path=/; HttpOnly;
Date: Wed, 24 Sep 2014 23:15:08 GMT
10986
<gzipped bytes>
Nb. hierboven heb ik de lange Cookie regels gewrapped, anders paste het niet in de breedte (en ik heb de 2e en 3e regel met Alt-255 spaties laten inspringen voor de leesbaarheid).
Opvallend is het ontbreken van "chunked encoding", gzip en "Vary: Accept-Encoding" in de Oops pagina.
Naast de content verschilt ook de wijze van verzenden
Er worden beide keren dan ook een verschillende pagina verzonden. Dus of dit nu zo vreemd is betwijfel ik?(nieuwsgierigheid:) kwamen beide pagina's van hetzelfde IP-adres?
Zojuist was het trouwens ook weer raak met http://www.tp-link.com/nl-be/: "Address not found".
Enkele keren kort achter elkaar geprobeerd: "addres not found".
http://nl.tp-link.com deed het nog wel goed.
En... amper 5 á 10 minuten later doet http://www.tp-link.com/nl-be/ het ook weer...
Mvg, cluc-cluc
25-09-2014, 19:23 door
Erik van Straten
Door cluc-cluc:
(nieuwsgierigheid:) kwamen beide pagina's van hetzelfde IP-adres?
De bovenkant en onderkant van de pagina zijn wel intact, alleen de verwachte content in het midden is soms vervangen door "oops". Ik heb het vanmiddag nog voor een collega kunnen reproduceren door enkele keren op F5 te drukken.Naast de content verschilt ook de wijze van verzenden
Er worden beide keren dan ook een verschillende pagina verzonden. Dus of dit nu zo vreemd is betwijfel ik?(nieuwsgierigheid:) kwamen beide pagina's van hetzelfde IP-adres?
support.microsoft.com heeft IP-adres 157.56.121.21. De webbrowser stuurt daar de request naartoe. Hierboven laat ik de relevante inhoud uit het eerste ontvangen antwoordpakket van 157.56.121.21 zien, zowel in de "Oops" situatie (code 404) als in de verwachte situatie (code 200). Later (na het parsen van de eerste ontvangen html) maakt de webbrowser ook verbindingen met andere servers, maar of het fout of goed gaat blijkt dus al uit het eerste antwoordpakket direct na het verzenden van een http request voor bijv. http://support.microsoft.com/kb/2977629.
Er gaat dus duidelijk iets mis ergens achter 157.56.121.21, dat hoogstwaarschijnlijk een loadbalancer is. "Iets" zal daar header, content en footer bij elkaar "praten", waarbij content minder statisch is dan header en footer, en dus vermoedelijk van een ander systeem afkomstig is. Kennelijk zijn er soms interne communicatieproblemen met dat "content" systeem.
Zoiets dus:
[content]
\
X (soms)
\
[mixer]---[157.56.121.21]---(internet)----[mijn PC]
/
/
/
[header+]
[footer ]
\
X (soms)
\
[mixer]---[157.56.121.21]---(internet)----[mijn PC]
/
/
/
[header+]
[footer ]
Hmmm...lijkt me moeilijk voor ons als end-users om op afstand met zekerheid de vinger op de zere plek te leggen.
Voelt intuïtief aan als zoiets als vermeld in mijn eerdere 23:25 bericht: backend servers waar de content vandaan moet komen die bijv. te traag zijn met hun respons, en dat hierdoor een soort "time-out" situatie ontstaat bij de mixer/loadbalancer, die bij zulke situaties dan voor de "oops" melding kiest. Maar het kan ook best wat anders zijn.
Op dit moment valt hier weinig te testen, want ik krijg nu steeds deze melding bij die beide MS webpages:
Server Error in '/' Application.
Runtime Error
Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
Er zit duidelijk iets niet helemaal lekker daar!
Mvg, cluc-cluc
Voelt intuïtief aan als zoiets als vermeld in mijn eerdere 23:25 bericht: backend servers waar de content vandaan moet komen die bijv. te traag zijn met hun respons, en dat hierdoor een soort "time-out" situatie ontstaat bij de mixer/loadbalancer, die bij zulke situaties dan voor de "oops" melding kiest. Maar het kan ook best wat anders zijn.
Op dit moment valt hier weinig te testen, want ik krijg nu steeds deze melding bij die beide MS webpages:
Server Error in '/' Application.
Runtime Error
Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
Er zit duidelijk iets niet helemaal lekker daar!
Mvg, cluc-cluc
Op dit moment valt hier weinig te testen, want ik krijg nu steeds deze melding bij die beide MS webpages:
Server Error in '/' Application. etc.
Update:Server Error in '/' Application. etc.
die error kreeg/krijg ik dus bij http://support.microsoft.com/kb/2977629 en http://support.microsoft.com/kb/2998527.
Inmiddels gaat het bij het beveiligde https bij mij wel goed.
Het valt op dat ik dan automatisch naar support2.microsoft.com verhuis.
Gebruik ik bij het onbeveiligde http ook: "support2.microsoft.com/(...) etc.", dan lijkt ook http nu goed te gaan.
Dus http://support2.microsoft.com/kb/2977629 en http://support2.microsoft.com/kb/2998527 lijken nu in orde.
(of nog beter: gebruik het beveiligde https)
Het toevoegen van support2 lijkt erop dat men extra resources heeft toegevoegd. (mogelijk om time-outs die leiden tot "oops" te voorkomen?) Maar op dit moment lijkt http://support.microsoft.com dus (nog) niet automatisch naadloos over te schakelen naar support2.microsoft.com) resulterend in een Runtime Error. Bij https heb je hier geen last van.
Mvg, cluc-cluc
27-09-2014, 18:14 door
Erik van Straten
@cluc-cluc: dank voor jouw onderzoek en bijdragen! Ik heb tussendoor ook gekeken en kan jouw bevindingen bevestigen.
Aanvankelijk kreeg ik een "gebroken slotje" (mixed content, dus zowel http als https op support2.microsoft.com) maar dat is ondertussen ook opgelost. Ik heb de "Oops" niet meer kunnen reproduceren.
Als je https://support.microsoft.com/kb/2977629 opent (23.102.36.254) wordt de belangrijkste content vanaf support2.microsoft.com (157.56.121.115) opgehaald (dus een iets ander IP-adres dan waar eerder deze week de problemen optraden, nl. 157.56.121.21).
Gezien de wijzigingen in Microsoft's CDN (Content Delivery Network) infrastructuur lijken de problemen opgelost enlaat ik dit onderwerp voorlopig rusten. Nogmaals dank aan allen die hebben meegedacht, ik vond het in elk geval leerzaam!
Off-topic, maar wat opvalt: van support2.microsoft.com krijg ik een SHA-2 certificaat, terwijl er onder water met verschillende andere sites verbinding gemaakt wordt die nog SHA1 certificaten gebruiken.
Een bijzonder griezelig SHA1 certificaat krijg je van https://ajax.aspnetcdn.com/ (68.232.34.200). Het subject daarvan is "*.vo.msecnd.net", maar het ondersteunt ook de volgende alternate names:
DNS Name=*.microsoft.com
DNS Name=*.msn-int.com
DNS Name=*.msn.com
DNS Name=*.live-int.com
DNS Name=*.windowsphone-int.com
DNS Name=*.windowsphone.com
DNS Name=*.cmsresources.windowsphone-int.com
DNS Name=*.marketplace.windowsmobile-int.com
DNS Name=*.wlxrs-int.com
DNS Name=*.shared.live-int.com
DNS Name=*.shared.live.com
DNS Name=*.wlxrs.com
DNS Name=*.cdn.office.net
DNS Name=*.ads2.msads.net
DNS Name=*.aspnetcdn.com
DNS Name=*.c3scs.jp.msn.com
DNS Name=*.cmsresources.windowsphone.com
DNS Name=*.f1ds.shared.live-int.com
DNS Name=*.f1ds.wlxrs-int.com
DNS Name=*.jp.msn.com
DNS Name=*.live-int.net
DNS Name=*.live.com
DNS Name=*.live.net
DNS Name=*.manage.microsoft.com
DNS Name=*.marketplace.windowsmobile-perf.com
DNS Name=*.marketplace.windowsmobile.com
DNS Name=*.microsoft-sbs-domains.com
DNS Name=*.msads.net
DNS Name=*.partner-df.windowsphone-int.com
DNS Name=*.partners.msn.com
DNS Name=*.s-msn.com
DNS Name=*.st.s-msn.com
DNS Name=*.stb.s-msn.com
DNS Name=*.stc.s-msn.com
DNS Name=*.stj.s-msn.com
DNS Name=*.wlxrsu-int.com
DNS Name=images.partner.windowsphone-int.com
DNS Name=images.partner.windowsphone.com
DNS Name=*.dev.skype.com
DNS Name=*.ucwa.lync.com
DNS Name=*.vo.msecnd.net
DNS Name=*.s.windows.microsoft.com
DNS Name=*.azureedge.net
DNS Name=*.wpc.azureedge.net
DNS Name=*.wac.azureedge.net
DNS Name=*.adn.azureedge.net
DNS Name=*.fms.azureedge.net
DNS Name=*.azurecomcdn.net
DNS Name=*.cdn.skype.net
DNS Name=*.cdn.skype.com
DNS Name=*.msdn.com
Als je SHA1 kunt kraken, d.w.z. de public key in dit certificaat kunt vervangen door een zelf gegenereerde en dit met andere wijzigingen in het certificaat combineert zodanig dat de SHA1sum over het certificaat niet wijzigt (de handtekening dus hetzelfde kan blijven), heb je in potentie een groot deel van Microsoft's infrastructuur ondermijnd.
Nb. dit certificaat en bijbehorende private key zijn waarschijnlijk in het bezit van de eigenaar van IP-adres 68.232.34.200, EdgeCast Networks, Inc. wat betekent dat ook andere dan Microsoft medewerkers hier mogelijk bij kunnen.
Aanvankelijk kreeg ik een "gebroken slotje" (mixed content, dus zowel http als https op support2.microsoft.com) maar dat is ondertussen ook opgelost. Ik heb de "Oops" niet meer kunnen reproduceren.
Als je https://support.microsoft.com/kb/2977629 opent (23.102.36.254) wordt de belangrijkste content vanaf support2.microsoft.com (157.56.121.115) opgehaald (dus een iets ander IP-adres dan waar eerder deze week de problemen optraden, nl. 157.56.121.21).
Gezien de wijzigingen in Microsoft's CDN (Content Delivery Network) infrastructuur lijken de problemen opgelost enlaat ik dit onderwerp voorlopig rusten. Nogmaals dank aan allen die hebben meegedacht, ik vond het in elk geval leerzaam!
Off-topic, maar wat opvalt: van support2.microsoft.com krijg ik een SHA-2 certificaat, terwijl er onder water met verschillende andere sites verbinding gemaakt wordt die nog SHA1 certificaten gebruiken.
Een bijzonder griezelig SHA1 certificaat krijg je van https://ajax.aspnetcdn.com/ (68.232.34.200). Het subject daarvan is "*.vo.msecnd.net", maar het ondersteunt ook de volgende alternate names:
DNS Name=*.microsoft.com
DNS Name=*.msn-int.com
DNS Name=*.msn.com
DNS Name=*.live-int.com
DNS Name=*.windowsphone-int.com
DNS Name=*.windowsphone.com
DNS Name=*.cmsresources.windowsphone-int.com
DNS Name=*.marketplace.windowsmobile-int.com
DNS Name=*.wlxrs-int.com
DNS Name=*.shared.live-int.com
DNS Name=*.shared.live.com
DNS Name=*.wlxrs.com
DNS Name=*.cdn.office.net
DNS Name=*.ads2.msads.net
DNS Name=*.aspnetcdn.com
DNS Name=*.c3scs.jp.msn.com
DNS Name=*.cmsresources.windowsphone.com
DNS Name=*.f1ds.shared.live-int.com
DNS Name=*.f1ds.wlxrs-int.com
DNS Name=*.jp.msn.com
DNS Name=*.live-int.net
DNS Name=*.live.com
DNS Name=*.live.net
DNS Name=*.manage.microsoft.com
DNS Name=*.marketplace.windowsmobile-perf.com
DNS Name=*.marketplace.windowsmobile.com
DNS Name=*.microsoft-sbs-domains.com
DNS Name=*.msads.net
DNS Name=*.partner-df.windowsphone-int.com
DNS Name=*.partners.msn.com
DNS Name=*.s-msn.com
DNS Name=*.st.s-msn.com
DNS Name=*.stb.s-msn.com
DNS Name=*.stc.s-msn.com
DNS Name=*.stj.s-msn.com
DNS Name=*.wlxrsu-int.com
DNS Name=images.partner.windowsphone-int.com
DNS Name=images.partner.windowsphone.com
DNS Name=*.dev.skype.com
DNS Name=*.ucwa.lync.com
DNS Name=*.vo.msecnd.net
DNS Name=*.s.windows.microsoft.com
DNS Name=*.azureedge.net
DNS Name=*.wpc.azureedge.net
DNS Name=*.wac.azureedge.net
DNS Name=*.adn.azureedge.net
DNS Name=*.fms.azureedge.net
DNS Name=*.azurecomcdn.net
DNS Name=*.cdn.skype.net
DNS Name=*.cdn.skype.com
DNS Name=*.msdn.com
Als je SHA1 kunt kraken, d.w.z. de public key in dit certificaat kunt vervangen door een zelf gegenereerde en dit met andere wijzigingen in het certificaat combineert zodanig dat de SHA1sum over het certificaat niet wijzigt (de handtekening dus hetzelfde kan blijven), heb je in potentie een groot deel van Microsoft's infrastructuur ondermijnd.
Nb. dit certificaat en bijbehorende private key zijn waarschijnlijk in het bezit van de eigenaar van IP-adres 68.232.34.200, EdgeCast Networks, Inc. wat betekent dat ook andere dan Microsoft medewerkers hier mogelijk bij kunnen.
Zou het wel werkbaar zijn als voor de lijst met alternate names die hierboven staat, voor elke DNS name een apart certificaat gebruik werd?
EdgeCast Networks, Inc. is ingelijfd door Verizon, vanouds een hechte Microsoft partner meen ik.
In ieder geval is het goedkoop om slechts één certificaat te gebruiken voor al die verschillende Microsoft websites.
Beter werkbaar? Wellicht.
Content delivery uitbesteden aan een "trusted partner"? Idemdito.
En nu maar hopen dat men zich goed heeft verdiept in ISO 27001 dat aan Microsoft is toegekend voor hun cloudy "Azure-services". (zonder vertaalfouten en begripsfouten... dat wel natuurlijk...)
In ieder geval is het goedkoop om slechts één certificaat te gebruiken voor al die verschillende Microsoft websites.
Beter werkbaar? Wellicht.
Content delivery uitbesteden aan een "trusted partner"? Idemdito.
En nu maar hopen dat men zich goed heeft verdiept in ISO 27001 dat aan Microsoft is toegekend voor hun cloudy "Azure-services". (zonder vertaalfouten en begripsfouten... dat wel natuurlijk...)
Door Anoniem 28-09-2014 15:39.:
EdgeCast Networks, Inc. is ingelijfd door Verizon, vanouds een hechte Microsoft partner meen ik.
In ieder geval is het goedkoop om slechts één certificaat te gebruiken voor al die verschillende Microsoft websites.
Beter werkbaar? Wellicht.
Content delivery uitbesteden aan een "trusted partner"? Idemdito.
En nu maar hopen dat men zich goed heeft verdiept in ISO 27001 dat aan Microsoft is toegekend voor hun cloudy "Azure-services". (zonder vertaalfouten en begripsfouten... dat wel natuurlijk...)
EdgeCast Networks, Inc. is ingelijfd door Verizon, vanouds een hechte Microsoft partner meen ik.
In ieder geval is het goedkoop om slechts één certificaat te gebruiken voor al die verschillende Microsoft websites.
Beter werkbaar? Wellicht.
Content delivery uitbesteden aan een "trusted partner"? Idemdito.
En nu maar hopen dat men zich goed heeft verdiept in ISO 27001 dat aan Microsoft is toegekend voor hun cloudy "Azure-services". (zonder vertaalfouten en begripsfouten... dat wel natuurlijk...)
Bedankt voor je reactie Anoniem 28-09-2014 15:39.
Bij meerdere certificaten zal je denk ik geen groepskorting krijgen ;-)
na update KB2998527 herhaaldelijk bluescreen. Na herstel zonder KB2998527 alles weer goed. Wat gaat hier mis?
Door Anoniem 29-09-2014 20:32: na update KB2998527 herhaaldelijk bluescreen. Na herstel zonder KB2998527 alles weer goed. Wat gaat hier mis?
Ik heb zojuist even op de website van Microsoft gekeken en niets kunnen vinden over problemen met deze update.
Misschien kun je iets meer informatie geven over je probleem?
Echter gaat dit topic niet over KB2998527 maar over ''support.microsoft.com''. Je zou je vraag in een nieuw topic kunnen stellen, om deze beter onder de aandacht te brengen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
