Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft mishandling example.com

tinyapps.org

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Microsoft mishandling example.com

#71

Post by somat »

EvanAnderson wrote: post #50
szszrk wrote: post #11

Earlier quoted context omitted.

My company used .local for EVERYTHING. I took it as normal at the time, until I got into problems with VMWARE products. Support patiently explained .local is reserved for something else and kindly provided Wikipedia links. They never responded why they used .local in their docs, trainings, webinars they provided, though :)

Things from docs making it into production is insidious. There were some early Sun docs that referenced a 129.9.0.0/16 network. Some helpful contractor in my locality, specializing in local government work, configured several police, fire, and city governments with that subnet internally back in the 90s. A few of them are still running that way today. I remember running into some oddball behavior with the Teredo adap…

Makes me remember the 192.1 addresses that were all over at one place I worked. "Um you know that is a valid internet address right?" "Yeah, but the guy who originally set the systems up was confused about the private address space, used the wrong one and we don't want to break anything so are not going to change it"

Good times.

Re: Microsoft mishandling example.com

#72

Post by p_ing »

lazide wrote: post #70
gruez wrote: post #69

Earlier quoted context omitted.

I don't think there's any evidence that windows sends cleartext passwords. The whole reason why NTLM is a thing is to avoid sending cleartext passwords.

Outlook appears to be

The 'https://' disagrees with your 'sending clear text passwords' statement.

Re: Microsoft mishandling example.com

#73

Post by stronglikedan »

GranPC wrote: post #12

> Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... " Wait, does their autodetect send email and password to their servers, instead of just domain???

See replies to a similar question here (in case you haven't already): https://news.ycombinator.com/item?id=46732623

Re: Microsoft mishandling example.com

#74

Post by dpifke »

emmelaich wrote: post #61

> The domain has a null MX record (indicating it doesn't accept email) Not quite true, SMTP will use the A record if there is no MX.

In this case, "null MX record" means MX exists, but does not specify a valid server:

   $ host -t mx example.com
   example.com mail is handled by 0 .
Senders should not fall back on the A record in this case.

Re: Microsoft mishandling example.com

#76

Post by kstrauser »

brulx126 wrote: post #36
gruez wrote: post #13

>Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... ": Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy…

Not just that, the new outlook app makes Microsoft a complete man-in-the-middle for your email account. https://www.xda-developers.com/privacy-implications-new-micr...

I am so glad people are finally noticing and complaining about this. It's the same reason I won't use Spark or Superhuman. Those are neat services, but I can't abide storing the creds to perhaps the most security-sensitive service I use to a cloud provider. If they get hacked, then the attacker can access my email account, send phishing emails to my contacts, read and respond to password reset requests they make to other online services, etc. It would be disastrous.

No, I'll keep my credentials stored and used locally, thanks.

Re: Microsoft mishandling example.com

#78

Post by encom »

brulx126 wrote: post #36
gruez wrote: post #13

>Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... ": Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy…

Not just that, the new outlook app makes Microsoft a complete man-in-the-middle for your email account. https://www.xda-developers.com/privacy-implications-new-micr...

So like Cloudflare for email.

Re: Microsoft mishandling example.com

#79

Post by technion »

GranPC wrote: post #12

> Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... " Wait, does their autodetect send email and password to their servers, instead of just domain???

Autodiscover has always been an interesting security problem. I wrote this years ago:

https://lolware.net/blog/2020-09-02-autodiscover-circus/

Re: Microsoft mishandling example.com

#80

Post by justsomehnguy »

ndriscoll wrote: post #21
irusensei wrote: post #5

Not surprised. They used to have training material incentivizing professionals to use .local as TLD for Active Directory realms. Thats a reserved domain for Multicast DNS. Working on Linux automation systems we would need to make sure to disable anything related to Avahi in our images otherwise name resolution would fail for some customers.

Haven't they been telling people to do that since before it became reserved? If so, the problem is more that you can't "reserve" something that's already in wide use, and mdns should've used something like .mdns. It's like when .dev became a gTLD, knowingly breaking a bunch of setups for a mix of vanity and a cash grab. Obviously dropped the ball on the engineering side.

> Haven't they been telling people to do that since before it became reserved

If you actually try to find an evidence for this (even time traveling to 2015 before the great wipe of most pre-Vista docs) you wouldn't find a confirmation for this. What you would find is what the official docs always recommended the root domain to be an official bought one on the public internet. And this excludes .local.

Post reply on HN